- From: Israel Hilerio <israelh@microsoft.com>
- Date: Fri, 5 Oct 2012 22:18:43 +0000
- To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
- CC: "jsbell@chromium.org" <jsbell@chromium.org>, Odin Hørthe Omdal (odinho@opera.com) <odinho@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>
On Wednesday, October 3, 2012 6:50 PM, Jonas Sicking wrote: >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.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
Received on Friday, 5 October 2012 22:19:24 UTC