W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: IndexedDB >> Proposed API Change: cursor.advance BACKWARD when direction is "prev"

From: Joshua Bell <jsbell@google.com>
Date: Wed, 21 May 2014 10:42:30 -0700
Message-ID: <CAD649j7=9vovipNYetk=OEBJmb0WPo=QFs2eTfUCdsfz1u2+KA@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Cc: marc fawzi <marc.fawzi@gmail.com>
On Wed, May 21, 2014 at 7:32 AM, Arthur Barstow <art.barstow@gmail.com>wrote:

> [ Bcc www-tag ; Marc - please use public-webapps for IDB discussions ]
> On 5/20/14 7:46 PM, marc fawzi wrote:
>> Hi everyone,
>> I've been using IndexedDB for a week or so and I've noticed that
>> cursor.advance(n) will always move n items forward regardless of cursor
>> direction. In other words, when the cursor direction is set to "prev" as
>> in: range = IDBKeyRange.only(someValue, "prev") and primary key is
>> auto-incremented, the cursor, upon cursor.advance(n), will actually advance
>> n items in the opposite direction to the cursor.continue() operation.
That runs contrary to the spec. Both continue() and advance() reference the
"steps for iterating a cursor" which picks up the direction from the cursor
object; neither entry point alters the steps to affect the direction.

When you say "you've noticed", are you observing a particular browser's
implementation or are you interpreting the spec? I did a quick test and
Chrome, Firefox, and IE all appear to behave as I expected when intermixing
continue() and advance() calls with direction 'prev' - the cursor always
moves in the same direction regardless of which call is used.

Can you share sample code that demonstrates the problem, and indicate which
browser(s) you've tested?

> This is not only an issue of "broken symmetry" but it presents an obstacle
>> to doing things like: keeping a record of the primaryKey of the last found
>> item (after calling cursor.continue for say 200 times) and, long after the
>> transaction has ended, call our search function again and, upon finding the
>> same item it found first last time, advance the cursor to the previously
>> recorded primary key and call cursor.continue 200 times, from that offset,
>> and repeat whenever you need to fetch the next 200 matching items. Such
>> algorithm works in the forward direction (from oldest to newest item)
>> because cursor.advance(n) can be used to position the cursor forward at the
>> previously recorded primary key (of last found item) but it does not work
>> in the backward direction (from newest to oldest item) because there is no
>> way to make the cursor advance backward. It only advances forward,
>> regardless of its own set direction.
>> This example is very rough and arbitrary. But it appears to me that the
>> cursor.advance needs to obey the cursor's own direction setting. It's
>> almost like having a car that only moves forward (and can't u-turn) and in
>> order to move backward you have to reverse the road. That's bonkers.
>> What's up with that?
>> How naive or terribly misguided am I being?
>> Thanks in advance.
>> Marc
Received on Wednesday, 21 May 2014 17:42:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC