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

I thought .continue/advance was similar to the 'continue' statement in a
for loop in that everything below the statement will be ignored and the
loop would start again from the next index. So my console logging was
giving confusing results. I figured it out and it works fine now. For
sanity's sake, I've resorted to adding a 'return'  in my code in the
.success callback after every .advance and .continue so the execution flow
is easier to follow. It's very confusing, from execution flow perspective,
for execution to continue past .continue/.advance while at once looping
asynchronously. I understand it's two different instances of the .success
callback but it was entirely not clear to me from reading the docs on MDN
(for example) that .advance / .continue are async.

Also, the description of .advance in browser vendor's documentation, e.g.
on MDN, says "Advance the cursor position forward by two places" for
cursor.advance(2) but what they should really say is "advance the cursor
position forward by two results." For example, let's say cursor first
landed on an item with primary key = 7, and you issue the statement
cursor.advance(2), I would expect it to go to the item with primary key 5
(for cursor direction = "prev") but instead it goes to the item with
primary key 2 because that's the 2nd match for the range argument from the
cursor's current position, which means that .advance(n) would be far more
clear semantically speaking if it was simply done as .continue(n)  ... I
guess if there is an understanding that the cursor is always at a matching
item and that it could only continue/advance to the next/prev matching
item, not literal 'positions' in the table (i.e. sequentially through the
list of all items) then there would be no confusion but the very concept of
a cursor is foreign to most front end developers, and that's where the
confusion comes from for many.

My inclination as a front end developer, so far removed from database
terminology, would be

1) to deprecate .advance in favor of .continue(n) and

2) if it makes sense (you have to say why it may not) have
.continue()/.continue(n) cause the return of the execution flow similar to
'continue' in a for loop.

What do you think?



On Wed, May 21, 2014 at 10:42 AM, Joshua Bell <jsbell@google.com> wrote:

>
>
>
> 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
>>>
>>
>>
>>
>