- From: Joshua Bell <jsbell@google.com>
- Date: Wed, 21 May 2014 10:42:30 -0700
- To: public-webapps <public-webapps@w3.org>
- Cc: marc fawzi <marc.fawzi@gmail.com>
- Message-ID: <CAD649j7=9vovipNYetk=OEBJmb0WPo=QFs2eTfUCdsfz1u2+KA@mail.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