[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: File tester.php    
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
$x = $c->ensureIndex(array('x'=>1), !$unique);
$c->insert(array('x'=>0));
$c->insert(array('x'=>0));

// count is 2
var_dump($c->count());

// create unique index, add two elements with the same value
$c->ensureIndex(array('z'=>1), $unique);
$c->insert(array('z'=>0));
$c->insert(array('z'=>0));

// I was expecting 3
var_dump($c->count());

...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
$x = $c->ensureIndex(array('x'=>1), !$unique);
$c->insert(array('x'=>0, 'z'=>1));
$c->insert(array('x'=>0, 'z'=>4));

// count is 2
var_dump($c->count());

$c->ensureIndex(array('z'=>1), $unique);
$c->insert(array('z'=>0));
$c->insert(array('z'=>0));

// count is 3
var_dump($c->count());

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
$c->ensureIndex(array('y'=>1), $unique);
$c->insert(array('y'=>0));
$c->insert(array('y'=>0));

// I was expecting 5, as the unique failed to hold before, but it was 4!
var_dump($c->count());

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
Tue Apr 21 10:18:46 CMD: drop foo.bar
Tue Apr 21 10:18:46 d->nIndexes was 2
Tue Apr 21 10:18:46 info: creating collection foo.bar on add index
Tue Apr 21 10:18:46 building new index on

{ x: 1 }

for foo.bar...done for 0 records
Tue Apr 21 10:18:46 building new index on

{ z: 1 }

for foo.bar...done for 2 records
Tue Apr 21 10:18:46 User Exception E11000 duplicate key error
Tue Apr 21 10:18:46 foo.bar Caught Assertion insert, continuing
Tue Apr 21 10:18:46 building new index on

{ y: 1 }

for foo.bar...Tue Apr 21 10:18:46 User Exception E11000 duplicate key error

d->nIndexes was 3
Tue Apr 21 10:18:46 foo.system.indexes Caught Assertion insert, continuing
Tue Apr 21 10:18:46 User Exception E11000 duplicate key error
Tue Apr 21 10:18:46 foo.bar Caught Assertion insert, continuing
Tue Apr 21 10:18:46 end connection 127.0.0.1:5008



 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:
Tue Apr 21 10:18:46 User Exception E11000 duplicate key error

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.

Generated at Thu Feb 08 02:52:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.