Re: IDBCursor should walk on secondary ordering of index value

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.

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?

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.