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

[Bug 20257] New: IDBCursor should walk on secondary ordering of index value

From: <bugzilla@jessica.w3.org>
Date: Wed, 05 Dec 2012 23:20:58 +0000
To: public-webapps@w3.org
Message-ID: <bug-20257-2927@http.www.w3.org/Bugs/Public/>

            Bug ID: 20257
           Summary: IDBCursor should walk on secondary ordering of index
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
          Assignee: dave.null@w3.org
          Reporter: kyawtun@yathit.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

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


Suppose, we have thousand of articles having tag to ‘javascript’, to find
the match we have to walk step-by-step.


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)

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.

This discussion can be found in

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 5 December 2012 23:21:02 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:50 UTC