On Wed, Oct 26, 2011 at 5:28 PM, Israel Hilerio <[email protected]> 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
