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: Fri, 2 Mar 2012 19:49:08 +0000
To: "jsbell@chromium.org" <jsbell@chromium.org>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E428E9A5E@TK5EX14MBXC115.redmond.corp.microsoft.com>
We would like some clarification on this scenario.  When you say that FF will result on 1 index entry for each index that implies that the duplicates are automatically removed.  That implies that the multiEntry flag doesn't take unique into consideration.  Is this correct?

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?

What happens during an update for a previously created index:
store = db.createObjectStore("store");
index1 = store.createIndex("index1", "a", { multiEntry: true });
store.add({ a: ["x", "y"]}, 1);
...
cursor.update({a: ["x", "x"]});
Does the index record get removed from the index relationships?  I imagine the answer is yes but wanted to validate with you.

Israel

On Friday, March 02, 2012 9:15 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:29 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
Hi All,

What should we do if an array which is used for a multiEntry index
contains multiple entries with the same value? I.e. consider the
following code:

store = db.createObjectStore("store");
index1 = store.createIndex("index1", "a", { multiEntry: true });
index2 = store.createIndex("index2", "b", { multiEntry: true, unique: true });
store.add({ a: ["x", "x"]}, 1);
store.add({ b: ["y", "y"]}, 2);

Does either of these adds fail? It seems clear that the first add
should not fail since it doesn't add any explicit constraints. But you
could somewhat make an argument that that the second add should fail
since the two entries would collide. The spec is very vague on this
issue right now.

However the first add really couldn't add two entries to index1 since
that would produce two entries with the same key and primaryKey. I.e.
there would be no way to distinguish them.

Hence it seems to me that the second add shouldn't attempt to add two
entries either, and so the second add should succeed.

This is how Firefox currently behave. I.e. the above code results in
the objectStore containing two entries, and each of the indexes
containing one.

If this sounds ok to people I'll make this more explicit in the spec.

That sounds good to me.

FWIW, that matches the results from current builds of Chromium.

-- Josh
Received on Friday, 2 March 2012 19:49:43 GMT

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