Re: IndexedDB: updates through cursors on indexes that change the key

On Tue, Feb 1, 2011 at 10:07 AM, Hans Wennborg <hans@chromium.org> wrote:

> For cursors on object stores, we disallow updates that change the key:
> one cannot provide an explicit key, and for object stores with a key
> path, the spec says that "If the effective object store of this cursor
> uses in-line keys and evaluating the key path of the value parameter
> results in a different value than the cursor's effective key, this
> method throws DATA_ERR."
>
> I suppose the reason is that an implementation may have trouble
> handling such updates, i.e. changing the keys that the cursor iterates
> over during the iteration is a bad idea.
>
> A similar situation can occur with cursors over indexes:
>
> Say that there is an object store with objects like {fname: 'John',
> lname: 'Doe', phone: 1234}, and an index with 'fname' as key path.
> When iterating over the index with a cursor, should it be allowed to
> update the objects so that the key in the index, in this case the
> 'fname', of an object is changed? The situation seems analogous to the
> one above, but as far as I can see, the spec does not mention this.
> Should it be allowed?
>
> I would be interested to hear your thoughts on this.
>

I think we should remove the original limitation instead.  While a cursor is
happening, anyone can call .remove() and .put() which is essentially the
same as doing an .update() which changes a key.  So implementations will
already need to handle this case one way or another.  What's there seems
like a fairly artificial limitation.

J