Re: [IndexedDB] Handling missing/invalid values for indexes

On Wed, Oct 26, 2011 at 5:28 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Monday, October 17, 2011 10:03 PM, Jonas Sicking wrote:
>> Hi All,
>>
>> Currently the spec is somewhat inconsistent in how it deals with having an
>> index on a property, and then inserting an object in an object store which is
>> either missing that property, or has the property but with a value which is not
>> a valid key.
>>
>> Consider a database which has been set up as follows:
>>
>> store = db.createObjectStore("mystore", { keyPath: "id" });
>> store.createIndex("myindex", "prop");
>>
>> As the spec currently stands (and which IIRC has been implemented in
>> Firefox), the following behavior is defined:
>>
>> store.put({ id: 1, prop: "a"}); // this will run successfully and will insert an
>> entry in the index with key "a"
>> store.put({ id: 2});  // this will run successfully and will not insert a entry in the
>> index store.put({ id: 3, prop: {}); // this will throw an exception
>>
>> I find this unfortunate for three reasons.
>>
>> * It seems it seems inconsistent to not require that a property is there, but
>> that if it's there, require it to contain a "proper" value.
>> * It means that you can't create an index without adding constraints on what
>> data can be stored.
>> * It means creating constraints on the data without any explicit syntax to
>> make that clear. Compare to the 'unique' constraint which has to be opted
>> into using explicit syntax.
>>
>> Also note that this doesn't just affect store.put and store.add calls.
>> It also affects what happens when you call createIndex. I.e. if you run the put
>> commands above first before creating the index, then that will obviously
>> succeed. If you then create the index as part of a VERSION_CHANGE
>> transaction, then the transaction will be aborted as the index can't be created.
>
> We have the same behavior as FF.
>
>>
>> Here is what I propose:
>>
>> I propose that we remove the requirement that we have today that if an
>> indexed property exists, it has to contain a valid value. Instead, if a property
>> doesn't contain a valid key value, we simply don't add an entry to the index.
>> This would of course apply both when inserting data into a objectStore which
>> already has indexes, as well as when creating indexes for an object store
>> which already contains data.
>
> This seems reasonable.

Cool. If I don't hear otherwise I'll make this change to the spec.

>> We have talked about adding a 'required' property for the options object in
>> the createIndex call, but haven't yet done so.  Once we do that (if that is in v1
>> or v2 is a separate question), such an explicit opt-in can require both that a
>> property exists, and that it contains a valid key value.
>>
>
> V2

Agreed.

/ Jonas

Received on Thursday, 27 October 2011 01:50:47 UTC