- 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>
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 UTC