[SERVER-3920] Get object IDs for mutated objects after an update Created: 21/Sep/11  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Write Ops
Affects Version/s: 2.0.0
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: ahildoer Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 6
Labels: SERVER_V2, update
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.04 64bit


Issue Links:
Related
related to SERVER-714 Allow findandmodify to retreive more ... Open
is related to SERVER-12858 Return detailed stats from write comm... Backlog
Assigned Teams:
Query Optimization
Participants:

 Description   

When an update is issued which mutates objects, I would like to be able to get an array of object IDs that were changed as a result of the update.



 Comments   
Comment by Asya Kamsky [ 07/May/18 ]

related to SERVER-714 (or might even be a duplicate)

 

Comment by Ian Whalen (Inactive) [ 15/Nov/12 ]

Anthony, no code has been committed for this feature yet and it is not yet scheduled. You'll see the relevant version in the Fix Version field when we do schedule this for a release.

Comment by ahildoer [ 15/Nov/12 ]

Ian,

I see you "made changes". Does this mean the feature is in the code and will come out eventually? If so, what stable version, 2.2.x or 2.4.x?

Thanks!

Comment by ahildoer [ 23/Mar/12 ]

Yes, findAndModify does this for one document. However, this request is for support for multiple documents, as the example in my first comment when I created the ticket indicates.

Comment by Glenn Maynard [ 23/Mar/12 ]

Apparently the findAndModify command-which is rather well-hidden in the documentation-can do this:

db.foo.findAndUpdate({query:

{a:1}

, update: {$set: {b:1}}, new: true);

The only downside is that you can't tell whether an upsert was an insert or an update, but it looks like that information is available, just discarded by findAndUpdate(), so that can be worked around by making the command directly.

(If findAndModify could avoid making a round-trip when fields is empty, it would obsolete update() entirely, so you wouldn't need to use very different API calls for similar operations.)

Comment by Glenn Maynard [ 01/Mar/12 ]

I've hit this problem, too. Inserts give you the _id and update gives you the _id if it's a new item, but update doesn't if you update a single item.

It would be better to support returning the entire updated record (optionally with field subsets). This would allow implementing atomic "return ++y" updates, atomically return the new value, among other things. Returning _id would be a simple case of this. (Since this would be more expensive, it probably shouldn't be the default, especially if it's supported for multi updates.)

Comment by ahildoer [ 21/Sep/11 ]

Some updates do not involve the _id at all. The filter is on other fields, however I may want to "listen" to changes on documents by _id.

For example, say I have the following collection:

> db.foo.find();

{ "_id" : ObjectId("4e791df2148d20c6f95cd3b9"), "a" : 1, "b" : 1 } { "_id" : ObjectId("4e7a2ed6f41c94f7270ebcbb"), "a" : 1 } { "_id" : ObjectId("4e7b2ed6f41c94f7248d20c6"), "a" : 1, "b" : 2 }

then I run:

> db.foo.update(

{a:1}

,{$set:{b:1}},false,true);

This update modifies documents with _id 4e7a2ed6f41c94f7270ebcbb and _id 4e7b2ed6f41c94f7248d20c6, adding the b field, and changing the value of the b field, respectively. Is there a way of getting those _ids back so I know what documents were modified by the update command? I don't seem to find anything that will work, especially with sharded collections.

Comment by Scott Hernandez (Inactive) [ 21/Sep/11 ]

Update doesn't change the _id values. The _id field is immutable.

If you do an update w/upsert then you may get a new document created and an ObjectId to go with it. You can check this after the update by following these directions: http://www.mongodb.org/display/DOCS/Updating#Updating-CheckingtheOutcomeofanUpdateRequest

Generated at Thu Feb 08 03:04:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.