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

On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell <jsbell@chromium.org> wrote:
> On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal <odinho@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.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.)

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

Received on Thursday, 4 October 2012 01:50:59 UTC