Re: [IndexedDB] KeyPaths and missing properties.

Interesting you'd bring this up.  Andrei and I were just looking at indexes
as specced and wondered whether it still makes sense to allow indexes to not
have a keyPath.  And, if so, whether we should tie insertion into the
objectStore to insertion to the index.  The main reason to make such changes
would be to enforce a notion of database consistency.  So I guess the
fundamental question here is whether there should be a 1:1 mapping between
entries in an objectStore's indexes and the objectStore itself.

On Wed, May 19, 2010 at 3:06 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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

If we went with (1) then it seems as though developers could simply insert
items with .phone=null to get around the limitation.

3 seems like it'd be error prone and somewhat confusing.

If we decide there should be a 1:1 mapping then it seems we're choosing
between 1 and 3.  And if not, then I think 2 is the clear answer.


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

Agreed.


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

This is probably just an omission in the spec.  If so, someone should file
an issue on it.


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

Agreed.


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

Hm.  I'm having trouble following this case.  Any chance you could explain
it further?

Thanks!
J