Re: findandmodify seems to use the wrong query on the update command

[mathias]

This is not actually a bug, but it does look weird in the profiler. We need to both used the exact _id as the matched object to make sure we updated the correct one and preserve the original query in order to support the $ operator in updates like update({comment.id: 1234}, {$inc: {comment.$.votes: 1}}). Leaving the $or in there won't hurt anything because it is implicitly anded with the explicit _id.

PS - it would be better to represent that query as {_id: {$in: ['1234', ObjectId('1234')]}}

PPS - you should generally avoid storing _id as a string form of an ObjectId.

 

On Wednesday, August 15, 2012 11:13:09 AM UTC-4, Sean Coates wrote:

Could someone offer insight on exactly what's happening here?

https://gist.github.com/3355357

Take a look at the query for the update (at line 44). Seems MongoDB is rewriting my query, but it leaves the original query in place. This seems to *work*, but why does it do this? (See also the comments on this gist; there's *some* insight in the code, but not much.)

The reason I stumbled upon this is that I was trying to do some scripted explains on my profile data, and got something like this: http://paste.roguecoders.com/p/efd3829bba5ab5fd19ba8bb1a073da6a.txt

Note the second clause (which should be entirely redundant because Mongo is selecting one explicit unique record (the _id)). This gives me an empty BasicCursor.

Is this a bug, and should it be filed as such? Seems like it to me, despite it technically "working" as-is (it would pass tests, I'm sure), but I wanted a sanity check before filing it in Jira.

Thanks.
S

[Sean Coates]

Aha. I thought the positional operator might be the culprit. Thanks for the explanation.

PS: indeed. thanks.

PPS: legacy carryover from our CouchDB to MongoDB migration. Fun, huh?