[IndexedDB] KeyPaths and missing properties.

Hi IndexedDB fans!

So another issue that's come up here. This question is orthogonal to
the other discussed issues and applies equally to both the existing
API, and the mozilla proposed API, so I figured it was safe to raise
right away.

What should happen if you insert a object into an objectStore which
has an index attached to it, but the property defined by the keyPath
in the index does not exist? Consider a database with an objectStore
called "people" with keyPath "name". The objectStore has an
auto-populated index named "phone numbers" with keyPath "phone". The
objectStore is initially empty.

What should happen if you attempt to store an object with value {
name: "Benny", email: "benny@sweden.com" } ?

There are three possible behaviors I can think of:

1. The storing operation should fail and an error event should be fired.
2. The storing operation should succeed, but no records should be
added to the "phone" index.
3. The storing operation should succeed and a record should be added
to the "phone" index using null as key.

Which one is correct behavior? What if the "phone numbers" index is
flagged as unique?

I definitely think there is a use case for allowing records to be
stored even if there are indexes on missing properties. Consider for
example a objectStore containing people where not everyone has a known
phone number. It still seems useful to be able to search based on
phone number in this objectStore. To satisfy this use case either
solution 2 or 3 would work. 3 would additionally allow searching for
everyone without a phone number, though I'm not sure how important
that is. On the other hand 2 would be more space effective in that
only relevant records would be stored.

Possibly we'll want to add a 'required' flag to the createIndex
function specifying if the index should cause behavior 1 or behavior
2. So far I'm not a big fan of 3, but I'm all ears for input.

The same question arises when an index is added to an objectStore
which has existing values that lack the property that the index uses
as keyPath. Whichever solution we go with above I think should be used
here too.


There is a similar issue if an objectStore uses in-line keys. Consider
a database with a objectStore called "people" with keyPath "name" and
no key generator. What if someone inserts an object with the value {
email: "benny@sweden.com" }? I would think that this should be an
error, but it doesn't appear that any of the steps in "Object Store
Storage steps" says to create an error.


Finally, there is the issue of what should happen if someone tries to
insert a number as a value into an objectStore with a keyPath and a
key generator. Consider the objectStore "albums" with keyPath "id" and
a key generator enabled. What should happen if someone tries to insert
the value 9 into this table? If an object was inserted, then this
would result in that objects 'id' property being set to the next
generated value from the generator, however it doesn't really make
sense to set a property on a number. Same question obviously applies
if the stored value is a boolean, a string, or any other primitive JS
type, or types such as regexps and File objects. I think that in all
these cases the operation should fail.

The question also applies if the stored value is an array. Technically
Javascript allows setting values on arrays, however the structured
clone algorithm drops these values, and so it seems to add needless
complexity for the implementation if the only time you need to
serialize/deserialize arrays with non-integer properties is in this
one case. Additionally, the id would be lost when the value is read as
that is done using the structured clone algorithm too.


/ Jonas

Received on Wednesday, 19 May 2010 03:12:03 UTC