Re: IDBCursor should walk on secondary ordering of index value

On Thu, Dec 6, 2012 at 6:47 AM, Joshua Bell <jsbell@chromium.org> wrote:

>
>
> On Wed, Dec 5, 2012 at 7:50 AM, Kyaw Tun <kyawtun@yathit.com> wrote:
>
>> Index records are stored in ascending order of key (index key) followed
>> by ascending order of value (primary key).
>>
>>
>> However, current IndexedDB API expose retrieving only by index key.
>>
>>
>> For example, the following operation on ‘tag‘ index of ‘article’ object
>> store  will retrieve the first occurrent of index key ‘javascript’.
>>
>>
>> IDBCursor_article_tag.continue(‘javascript’)
>>
>>
>> Suppose, we have thousand of articles having tag to ‘javascript’, to find
>> the match we have to walk step-by-step.
>>
>>
>> IDBCursor_article_tag.continue()
>>
>>
>> This take linear time whereas it is possible with log time on database
>> engine. Additionally we are making unnecessary callbacks back-and-ford
>> between js and database engine.
>>
>>
>> Such use case is common on filtered query and join operations. In these
>> case, index key is held constance while walking on primary keys.
>>
>>
>> It will be good if IndexedDB API provide like:
>>
>>
>> IDBCursor_article_tag.continue(index_key, primary_key)
>>
>>
>> Agreed. We've also had several requests for this sort of
> 'continuePrimaryKey' method.
>

While continuing on primary key, these use cases require index key not
change.


>
> You've done a great job at explaining the use case. Can you file a bug at
> https://www.w3.org/Bugs under Product: WebAppsWG and component: Indexed
> Database API?
>
>  It is a bit strange since the result is again primary_key. We already
> know primary_key from other filter condition.
>
>>
>> This method is also useful for cursor resume process.
>>
>>
>> Probably IDBCursor.advance(count) should take negative integer value as
>> well.
>>
> Do you have a scenario in mind?
>

No. I do not need it so far. I wanted to peek it before continuing, but it
is not an important use case.


>
> The request makes sense, I just haven't heard this one before. It would be
> the first time we have a cursor "change direction", and while I don't think
> it's difficult in our implementation it could use some additional
> justification. How this plays with "prevunique" / "nextunique" also needs
> defining.
>
>
I think, cursor direction should not change. Cursor position just
steps backward. If direction changes require, a new cursor should be
created instead.