[SERVER-5691] Queries with nested collections fail after MongoDB reorders fields post-update Created: 24/Apr/12 Updated: 15/Aug/12 Resolved: 24/Apr/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Arun Bhalla | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux: OSX (10.6.8): MongoDB 2.0.4 |
||
| Operating System: | ALL |
| Participants: |
| Description |
|
We are developing a straightforward Scala web application with a MongoDB backend using Salat+Casbah. We've noticed that sometimes our updates via Salat+Casbah fail to succeed. I can now explain why it's happening:
Although we ran into this issue using Salat+Casbah, I was able to reproduce it using the Mongo CLI:
For some reason, this issue only surfaces with nested documents, despite claims that key order is significant in queries. For example, the above inserted object will be found by both of the following queries:
I gather that both the significance of key ordering and the potential field re-ordering of documents are both by design, but the interaction between these two aspects seems to be a bad bug; the application runs fine until MongoDB needs to re-order fields in some documents. This is a subtle and unexpected bug, in part because the significance of key ordering in queries and documents is hardly documented at all. |
| Comments |
| Comment by Arun Bhalla [ 25/Apr/12 ] | |||||
|
To be clear, MongoDB reordered the fields in the embedded documents. My example simulates that in order to reproduce the issue. I think the intersection of these two MongoDB design choices described above surfaces as a bug, but we will pursue one of your suggestions. Thanks. | |||||
| Comment by Scott Hernandez (Inactive) [ 24/Apr/12 ] | |||||
|
You should use a version number combined with the id to do this kind of optimistic locking. See this article: http://code.google.com/p/morphia/wiki/MongoNewsletterArticleDec2010 Your document is the not the same as the query since you reordered fields in embedded docs and are comparing them. See the documentation on using docs as keys/for-lookups : http://www.mongodb.org/display/DOCS/Indexes#Indexes-UsingDocumentsasKeys If you really wanted to make that a query you would need to use dot-notation like this:
| |||||
| Comment by Arun Bhalla [ 24/Apr/12 ] | |||||
|
Some related issues: |