Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(NODE-1812): Deprecate returnOriginal in favor of returnDocument #2808

Merged
merged 1 commit into from
May 17, 2021

Conversation

dariakp
Copy link
Contributor

@dariakp dariakp commented May 12, 2021

Description

NODE-1812

Deprecated returnOriginal in favor of returnDocument option in order to conform with shared drivers spec for findOneAndReplace() and findOneAndUpdate() collection methods.

@dariakp dariakp force-pushed the NODE-1812/3.6/deprecate-returnOriginal-option branch from 8a88a1f to 024c865 Compare May 12, 2021 21:55
…ent option in findOneAndReplace and findOneAndUpdate methods
@dariakp dariakp force-pushed the NODE-1812/3.6/deprecate-returnOriginal-option branch from 024c865 to 683d000 Compare May 12, 2021 21:56
@dariakp dariakp marked this pull request as ready for review May 12, 2021 22:25
@dariakp dariakp requested review from a team, durran, emadum and nbbeeken and removed request for a team May 12, 2021 22:25
Copy link
Contributor

@nbbeeken nbbeeken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

@emadum emadum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small request on the type of error thrown, other than that LGTM 👍

const FindAndModifyOperation = require('./find_and_modify');
const hasAtomicOperators = require('../utils').hasAtomicOperators;

class FindOneAndReplaceOperation extends FindAndModifyOperation {
constructor(collection, filter, replacement, options) {
if ('returnDocument' in options && 'returnOriginal' in options) {
throw new MongoError(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
throw new MongoError(
throw new TypeError(

I think this would be more appropriate than MongoError

Copy link
Contributor Author

@dariakp dariakp May 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually disagree with this use of TypeError, because a TypeError to a developer is usually an indication that the wrong data type was passed in, which in this case isn't true of the individual options. If we consider the entirety of the options object as being of a particular type (defined by the allowed combinations of keys), TypeError might technically be applicable, but I think it's a bit odd to do type validation on a dictionary as a whole instead of individual members (particularly when we don't actually validate any of the other options at the same time). What we really need is a validation error type as distinct from a server or other sort of error; unfortunately, the driver currently silently overwrites options in the other cases of deprecation and actual option validation is sparse and examining the code base, most of the other instances of non-type-related option validation use MongoError, hence its use here for consistency.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other errors like this throw TypeErrors; I think it would be good to be consistent, though I don't feel strongly about this kind of errors being TypeErrors and would be OK with a new error type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah those definitely should not be TypeErrors. And aside from the read preference file, other places do use MongoError:

export function checkCollectionName(collectionName: string): void {
if ('string' !== typeof collectionName) {
throw new MongoError('collection name must be a String');
}
if (!collectionName || collectionName.indexOf('..') !== -1) {
throw new MongoError('collection names cannot be empty');
}
if (
collectionName.indexOf('$') !== -1 &&
collectionName.match(/((^\$cmd)|(oplog\.\$main))/) == null
) {
throw new MongoError("collection names must not contain '$'");
}
if (collectionName.match(/^\.|\.$/) != null) {
throw new MongoError("collection names must not start or end with '.'");
}
// Validate that we are not passing 0x00 in the collection name
if (collectionName.indexOf('\x00') !== -1) {
throw new MongoError('collection names cannot contain a null character');
}
}

https://github.com/mongodb/node-mongodb-native/blob/4.0/src/operations/aggregate.ts#L76
https://github.com/mongodb/node-mongodb-native/blob/4.0/src/db.ts#L756
with the cleanest example using the MongoParseError:
https://github.com/mongodb/node-mongodb-native/blob/4.0/src/connection_string.ts#L136
right now though the MongoParseError is limited to the connection string parsing and I'm not sure we want to expand its use elsewhere

const FindAndModifyOperation = require('./find_and_modify');
const hasAtomicOperators = require('../utils').hasAtomicOperators;

class FindOneAndUpdateOperation extends FindAndModifyOperation {
constructor(collection, filter, update, options) {
if ('returnDocument' in options && 'returnOriginal' in options) {
throw new MongoError(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@emadum emadum self-requested a review May 17, 2021 16:38
@dariakp dariakp merged commit f916843 into 3.6 May 17, 2021
@dariakp dariakp deleted the NODE-1812/3.6/deprecate-returnOriginal-option branch May 17, 2021 17:52
barisusakli added a commit to NodeBB/NodeBB that referenced this pull request May 28, 2021
alecgibson added a commit to reedsy/mongodb-queue that referenced this pull request Jun 29, 2021
The `mongodb` Node.js driver deprecated use of `returnOriginal` in
favour of `returnDocument` in [v3.6][1].

This non-breaking change allows consumers to opt in to using the newer
`returnDocument` by setting an option on construction

```js
var queue = mongoDbQueue(db, 'queue', { returnDocument : true })
```

[1]: mongodb/node-mongodb-native#2808
alecgibson added a commit to reedsy/mongodb-queue that referenced this pull request Jun 29, 2021
The `mongodb` Node.js driver deprecated use of `returnOriginal` in
favour of `returnDocument` in [v3.6][1].

This non-breaking change allows consumers to opt in to using the newer
`returnDocument` by setting an option on construction

```js
var queue = mongoDbQueue(db, 'queue', { returnDocument : true })
```

[1]: mongodb/node-mongodb-native#2808
alecgibson added a commit to reedsy/mongodb-queue that referenced this pull request Jun 29, 2021
The `mongodb` Node.js driver deprecated use of `returnOriginal` in
favour of `returnDocument` in [v3.6][1].

This non-breaking change allows consumers to opt in to using the newer
`returnDocument` by setting an option on construction

```js
var queue = mongoDbQueue(db, 'queue', { returnDocument : true })
```

[1]: mongodb/node-mongodb-native#2808
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants