[SERVER-26] Unique index behavior inconsistent Created: 21/Apr/09 Updated: 22/May/09 Resolved: 22/May/09 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kristina Chodorow (Inactive) | Assignee: | Aaron Staple |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Participants: |
| Description |
|
I think I found a bug in the unique index thing. Sometimes the unique index works, sometimes it doesn't. I was writing a test for it and when I do: // create non-unique index, add two elements with the same value // count is 2 // create unique index, add two elements with the same value // I was expecting 3 ...but it's 4. Okay, I thought, so maybe the theory is that the {'x' : 0}elements implicitly have the same 'z' value, so it's creating a normal index for 'z', even though I'm asking for a unique index. This was supported by the fact that this worked: // same as above, except setting the 'z' field // count is 2 $c->ensureIndex(array('z'=>1), $unique); // count is 3 So then I added a test creating a third index, to test my theory: // create a unique index on 'y', which none of the elements have set // I was expecting 5, as the unique failed to hold before, but it was 4! So, I have no idea what's going on. I'm guessing it's a bug with the unique index code. Database output for running the whole test: Tue Apr 21 10:18:46 connection accepted from 127.0.0.1:50082 for foo.bar...done for 0 records for foo.bar...done for 2 records for foo.bar...Tue Apr 21 10:18:46 User Exception E11000 duplicate key error d->nIndexes was 3 |
| Comments |
| Comment by Kristina Chodorow (Inactive) [ 22/May/09 ] |
|
Thanks for figuring out, that makes sense. |
| Comment by Aaron Staple [ 22/May/09 ] |
|
Sorry, I was misreading the bug report before – the described behavior is expected. Adding a {y:1}unique index fails because multiple existing objects would have {y:null}keys. Only one {y:0}object may be inserted because each such object has a {z:null}key in the {z:1}unique index so only one such object is allowed. |
| Comment by Aaron Staple [ 22/May/09 ] |
|
I tried to reproduce this with the js shell but didn't see the bug. Going to try running the php version locally. |
| Comment by Kristina Chodorow (Inactive) [ 19/May/09 ] |
|
no, still broken. |
| Comment by Eliot Horowitz (Inactive) [ 15/May/09 ] |
|
did we ever resolve this? |
| Comment by Kristina Chodorow (Inactive) [ 21/Apr/09 ] |
|
Sometimes it does and sometimes it doesn't, though. It fails when I create it for 'x', but succeeds for 'y'. |
| Comment by Eliot Horowitz (Inactive) [ 21/Apr/09 ] |
|
Take a look at the server log: When you try to create the unique index, it fails because there are 2 objects with the same value for z If you call getlasterror() you should get that. |