[SERVER-6775] findandmodify incorrectly modifies/optimizes the query for the update operation Created: 15/Aug/12 Updated: 15/Feb/13 Resolved: 16/Aug/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Sean Coates | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 0 |
| Labels: | findAndModify, profiling, update | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux. Looks like it happens everywhere, in the code. |
||
| Operating System: | Linux |
| Participants: |
| Description |
|
Console session: 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. (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. From here: https://groups.google.com/d/topic/mongodb-user/we4kDRdE4GM/discussion (Kristina and Derick both suggested I file this in Jira). |
| Comments |
| Comment by Sean Coates [ 16/Aug/12 ] |
|
I guess you can close this. It's still really confusing (the way it shows up in the profiler), but may not actually be a bug after all. |
| Comment by Aaron Staple [ 15/Aug/12 ] |
|
Hi Sean, It should work fine generally. Here's a bit of an explanation. Your example is basically { $or:[ { _id:A }, { _id:B }] } In the example you sent the explain link from it's getting transformed to { _id:A, $or:[ { _id:A }, { _id:B }] } The second $or clause can't produce any results, so what you're seeing when explaining the second clause is a dummy basic cursor that doesn't scan anything. There is a ticket to make this reporting more user friendly, We could potentially remove $or clauses when find and modify rewrites the query, since the positional operator doesn't look inside $or clauses. This might make the queries a bit faster but is probably not strictly necessary. (I haven't worked on the find and modify code myself though.) |
| Comment by Sean Coates [ 15/Aug/12 ] |
|
The only practical error I've seen is that in .explain() I get a BasicCursor that showed up as non-indexed in my analysis tools. It seems to work just fine as it it, but I'm not sure that would be the case for every similar query. S |
| Comment by Aaron Staple [ 15/Aug/12 ] |
|
Sean - are you experiencing a functional error of some kind? |