W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 27 Oct 2011 00:28:18 +0000
To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, "Jim Wordelman" <jaword@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F51D4E0@TK5EX14MBXC115.redmond.corp.microsoft.com>
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.

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

> Let me know what you think.
> 
> / Jonas
> 

Israel
Received on Thursday, 27 October 2011 00:28:46 GMT

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