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.

Received on Wednesday, 3 October 2012 08:14:17 UTC