IDBCursor should walk on secondary ordering of index value

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)


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.


Best regards,

Kyaw