Re: [IndexedDB] Multientry and duplicate elements

Awesome, I've updated the spec to hopefully be clear on this.

/ Jonas

On Mon, Mar 5, 2012 at 12:09 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> 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 Tuesday, 6 March 2012 02:45:55 UTC