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
Re: IDBCursor should walk on secondary ordering of index value
On Wed, Dec 5, 2012 at 7:50 AM, Kyaw Tun 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.
[Bug 20257] New: IDBCursor should walk on secondary ordering of index value
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20257 Bug ID: 20257 Summary: IDBCursor should walk on secondary ordering of index value Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: kyaw...@yathit.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@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’. 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. This discussion can be found in http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0654.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 20257] IDBCursor should walk on secondary ordering of index value
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20257 Joshua Bell changed: What|Removed |Added Status|NEW |RESOLVED CC||jsb...@chromium.org Resolution|--- |LATER --- Comment #1 from Joshua Bell --- +1 - Chromium has also received this feedback from developers. Resolving for later, but it's an obvious win for IDB v2. -- You are receiving this mail because: You are on the CC list for the bug.
Re: IDBCursor should walk on secondary ordering of index value
On Thu, Dec 6, 2012 at 6:47 AM, Joshua Bell wrote: > > > On Wed, Dec 5, 2012 at 7:50 AM, Kyaw Tun 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.
