Conversation
8a88a1f to
024c865
Compare
…ent option in findOneAndReplace and findOneAndUpdate methods
024c865 to
683d000
Compare
emadum
left a comment
There was a problem hiding this comment.
One small request on the type of error thrown, other than that LGTM 👍
| class FindOneAndReplaceOperation extends FindAndModifyOperation { | ||
| constructor(collection, filter, replacement, options) { | ||
| if ('returnDocument' in options && 'returnOriginal' in options) { | ||
| throw new MongoError( |
There was a problem hiding this comment.
| throw new MongoError( | |
| throw new TypeError( |
I think this would be more appropriate than MongoError
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah those definitely should not be TypeErrors. And aside from the read preference file, other places do use MongoError:
node-mongodb-native/src/utils.ts
Lines 55 to 79 in 1cdc8a8
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
| class FindOneAndUpdateOperation extends FindAndModifyOperation { | ||
| constructor(collection, filter, update, options) { | ||
| if ('returnDocument' in options && 'returnOriginal' in options) { | ||
| throw new MongoError( |
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
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
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
Description
NODE-1812
Deprecated
returnOriginalin favor ofreturnDocumentoption in order to conform with shared drivers spec forfindOneAndReplace()andfindOneAndUpdate()collection methods.