W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: IDBCursor should walk on secondary ordering of index value

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 5 Dec 2012 14:47:24 -0800
Message-ID: <CAD649j7AXM9UZuJmLL8ov0eSXaXCC6GvW=aD29nrtUrEK8FK=Q@mail.gmail.com>
To: Kyaw Tun <kyawtun@yathit.com>
Cc: public-webapps@w3.org
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.
Received on Wednesday, 5 December 2012 22:47:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT