Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

Without checking (I'm waiting for the bus in the rain) I can say we also do it like this. It is actually in the spec if you read it dead carefully, it's just not that obvious.

It will first do the range getting, and then it will take the item on top sorted secondarily by value. And in an index the «value» is actually the key to the primary record.

There is a note near the algorithm saying something to that point, but the definite text is up in the prose "let's explain IDB" section IIRC.

It's not really clear IMHO. I believe I have written a few tests for it.

Standard early morning not yet at work and without the spec in front of me disclaimer :) 
 
--
 
Sent from my N9, excuse the top posting
 


On 03.10.12 03:37 Israel Hilerio wrote:

We noticed there is consistent behavior between FF v.15.0.1 and Chrome v.24.0.1284.0 canary that we believe is a bug when dealing with both ‘prevunique’ and ‘nextunique’.  Below is what we’re seeing using the following site http://jsbin.com/iyobis/10/edit
 
For the following data set (keypath = ‘id’)
{id:1, a: 'foo' };
{id:2, a: 'bar' };
{id:3, a: 'foo' };
 
When we open the cursor with prevunique and nextunique, on an index on ‘a’ using IDBKeyRnage.only(‘foo’) we get the following record back:
{id:1, a: 'foo' };
 
For the data above, it seems like there should be different return values for prevunique and nextunique based on the definitions on the spec.
 
Our expectation was that for prevunique we would get the following record:
{id:3, a: 'foo' };
The reason being that the bottom of our index list starts with id:3.
 
And for nextunique we would get the following record:
{id:1, a: 'foo' };
The reason being that the top of our index list starts with id:1.
 
Since we’re seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design.
 
Can you confirm?
Thanks,
 
Israel