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

Re: [IndexedDB] Multientry and duplicate elements

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 4 Mar 2012 03:24:15 +0100
Message-ID: <CA+c2ei97F6SfburE5+nzfudYLBGMjNUPEr5nTx6JRy46=jd4nQ@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "jsbell@chromium.org" <jsbell@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
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 Sunday, 4 March 2012 02:25:12 GMT

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