If findAndModify experiences an error, the obj argument to the callback
is undefined. Instead the lastErrorObject is attached to the err
argument, from where we extract it.
To not rely on the lastErrorObject ALWAYS being on the err object if
provided, we gracefully fall back to looking in the obj object and then
finally just return { n: 0 } if no lastErrorObject is found. This could
be a more strict algorihm, but this seems more future-proof.
- If the function was called with an array, the callback will have an array (even if the array had one element).
- If it was called with an object, the callback will have an object.
After this commit the callbacks for the write functions are as follows.
```
db.users.insert(document, callback); // => callback(err, [document])
db.users.save(document, callback); // => callback(err, document)
db.users.update({ ... }, { ... }, callback); // => callback(err, lastErrorObject)
db.users.remove({ ... }, callback); // => callback(err, {n: amountRemoved})
db.users.findAndModify({ query: { ... }, update: { ... }}, callback); // => callback(err, document, lastErrorObject)
```
The reason for these changes is that sometimes you might want to save a document and retrieve the
ObjectId it was saved with.
The problem of `save` returning '1' when the operation was an update is solved
here, and a test case was added for this as well.
If you have collection names which are identical to functions in the mongodb-native you will get in trouble with the changes on the db prototype (a37030ac93 and 26d17aa20f).
This small fix changes the behaviour:
If you initialize collection names with the connect they will overwrite the prototype functions.
If you use the explicit collection() you will always get the collection and not the possible available prototype function.
Eduardo Sorribas
Mathias Buus
Thomas Watson Steen
Mirza Kapetanovic
RG72
Forbes Lindesay
Markus