W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

RE: [IndexedDB] Multientry and duplicate elements

From: Israel Hilerio <israelh@microsoft.com>
Date: Mon, 5 Mar 2012 20:09:57 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "jsbell@chromium.org" <jsbell@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E428EC70E@TK5EX14MBXC115.redmond.corp.microsoft.com>
I was originally referring to the second scenario.  However, I agree with you that we shouldn't support this scenario.  I just wanted to confirm this.
Thanks,

Israel

On Saturday, March 03, 2012 6:24 PM, Jonas Sicking wrote:
> On Fri, Mar 2, 2012 at 8:49 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> > There seems to be some cases where it might be useful to be able to
> > get a count of all the duplicates contained in a multiEntry index.  Do
> > you guys see this as an important scenario?
> 
> Not exactly sure what you mean here.
> 
> Do you mean duplicates in the form of the same value existing for multiple
> entries, i.e. (assuming there's an index on the 'a' property)
> 
> store.add({ a: [10, 20], ... }, 1);
> store.add({ a: [10, 30], ... }, 2);
> 
> here there's a duplicate of the value 10. I.e. here you can count the duplicates
> by doing:
> 
> index.count(10).onsuccess = ...;
> 
> This will give 2 as result.
> 
> Or do you mean duplicates in the form of the same value existing for the same
> entry, i.e.:
> 
> store.add({ a: [30, 30] }, 3);
> 
> Currently in firefox this won't produce a duplicate entry in the index. I.e.
> 
> index.count(30).onsuccess = ...;
> 
> will give 1 as result.
> 
> It seems to me that it would introduce a lot of complexities if we were to insert
> two rows here to allow tracking duplicates. First of all there would be no way
> to tell the two entries apart using the API that we have now which seems like it
> could be problematic for pages.
> Second, cursor's iteration is currently defined in terms of going to the next
> entry which has a higher key than the one the cursor is currently located at. So
> if two entries have the exact same key, the cursor would still skip over the
> second one of them. In other words, we would have to redefine cursor
> iteration.
> 
> This is all certainly doable, but it seems non-trivial.
> 
> It would also complicate the datamodel in the implementation since the index
> would no longer be simply a btree of indexKey + primaryKey. An additional key
> would need to be added in order to tell duplicate entries apart.
> 
> / Jonas
Received on Monday, 5 March 2012 20:10:37 GMT

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