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

[ 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. 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 14:32:43 UTC