RE: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor
On Wednesday, October 3, 2012 6:50 PM, Jonas Sicking wrote: On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell jsb...@chromium.org wrote: On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal odi...@opera.com wrote: So, at work and with the spec in front of me :-) Odin claimed: 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. Nope, this was wrong, it's actually right there in the algorithm: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps -for-iterating-a-cursor # If direction is prevunique, let temp record be the last record in # records which satisfy all of the following requirements: # # If key is defined, the record's key is less than or equal to key. # If position is defined, the record's key is less than position. # If range is defined, the record's key is in range. # # If temp record is defined, let found record be the first record in # records whose key is equal to temp record's key So it'll find the last foo, and then, as the last step, it'll find the top result for foo, giving id 1, not 3. The prevunique is the only algo that uses that temporary record to do its search. I remember this text was somewhat different before, I think someone clarified it at some point. At least it seems much clearer to me now than it did the first time. Since I have it the link handy - discussed/resolved at: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.htm l Israel Hilerio said: Since we're seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design. It would bet several pennies its by design, because the spec needs more framework to explain this than it would've needed otherwise. What that exact design was (rationale et al) I don't know, it was before my time I guess. :-) Yes, the behavior in Chrome is by design to match list consensus. (FWIW, it's extra code to handle this case, and we've had bug reports where we had to point at the spec to explain that we're actually following it, but presumably this is one of those cases where someone will be confused by the results regardless of which approach was taken.) Yes, this was very intentional. The goal was that reverse iteration would always return the same set of rows as forward iteration, just in reverse order. This seemed like the most easily understandable and explainable behavior. Consider for example a UI which renders an address book grouped by first letter and showing the first name in that letter. It would seem strange if the user changing z-a or a-z shows different names. / Jonas Thanks everyone for the explanations. Jonas, your last example clarified things for me. We'll file a bug on our side. Israel
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
Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor
So, at work and with the spec in front of me :-) Odin claimed: 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. Nope, this was wrong, it's actually right there in the algorithm: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-iterating-a-cursor # If direction is prevunique, let temp record be the last record in # records which satisfy all of the following requirements: # # If key is defined, the record's key is less than or equal to key. # If position is defined, the record's key is less than position. # If range is defined, the record's key is in range. # # If temp record is defined, let found record be the first record in # records whose key is equal to temp record's key So it'll find the last foo, and then, as the last step, it'll find the top result for foo, giving id 1, not 3. The prevunique is the only algo that uses that temporary record to do its search. I remember this text was somewhat different before, I think someone clarified it at some point. At least it seems much clearer to me now than it did the first time. Israel Hilerio said: Since we’re seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design. It would bet several pennies its by design, because the spec needs more framework to explain this than it would've needed otherwise. What that exact design was (rationale et al) I don't know, it was before my time I guess. :-) -- HØRTHE OMDAL, ODIN* Velmont/odinho · Core, Opera Software, http://opera.com *: Sorry sorry sorry for top-posting in my previous phone-sent email. My in-email excuse wasn't accepted, and I received flames and punishment when I came to work. I apologize for littering your inboxes.
Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor
On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal odi...@opera.com wrote: So, at work and with the spec in front of me :-) Odin claimed: 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. Nope, this was wrong, it's actually right there in the algorithm: http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/** Overview.html#dfn-steps-for-**iterating-a-cursorhttp://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-iterating-a-cursor # If direction is prevunique, let temp record be the last record in # records which satisfy all of the following requirements: # # If key is defined, the record's key is less than or equal to key. # If position is defined, the record's key is less than position. # If range is defined, the record's key is in range. # # If temp record is defined, let found record be the first record in # records whose key is equal to temp record's key So it'll find the last foo, and then, as the last step, it'll find the top result for foo, giving id 1, not 3. The prevunique is the only algo that uses that temporary record to do its search. I remember this text was somewhat different before, I think someone clarified it at some point. At least it seems much clearer to me now than it did the first time. Since I have it the link handy - discussed/resolved at: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.html Israel Hilerio said: Since we’re seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design. It would bet several pennies its by design, because the spec needs more framework to explain this than it would've needed otherwise. What that exact design was (rationale et al) I don't know, it was before my time I guess. :-) Yes, the behavior in Chrome is by design to match list consensus. (FWIW, it's extra code to handle this case, and we've had bug reports where we had to point at the spec to explain that we're actually following it, but presumably this is one of those cases where someone will be confused by the results regardless of which approach was taken.)
