- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 15 Sep 2010 14:45:11 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-webapps WG <public-webapps@w3.org>
Heh, I've also been thinking about this exact issue lately. There is a
similar question for IDBCursor.delete.
On Wed, Sep 15, 2010 at 8:55 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> I think it's clear what IDBCursor does when created from
> IDBObjectStore.openCursor or IDBIndex.openObjectCursor: it modifies the
> objectStore's value and updates all indexes (or does nothing and returns an
> error if all of that can't be done while satisfying the constraints).
Agreed.
> But what about IDBCursor.update when created from IDBIndex.openCursor? I
> see two options: we could modify the value within the objectStore's value
> that corresponds to the objectStore's key path or we could do like above and
> simply modify the objectStore's value.
There's also a third option: Throw an exception. Maybe that's what
you're referring to by "make this unsupported" below?
> More concretely, if we have an object store with a "id" key path and an
> index with a "fname" key path, and our index.openCursor() created cursor is
> currently on the {id: 22, fname: "Fred"} value (and thus cursor.key ==
> "Fred" and cursor.value == 22), let's say I wanted to change the object to
> be {id: 23, fname: "Fred"}. In other words, I want id to change from 22 to
> 23. Which of the following should I write?
> 1) calling cursor.update(23) or
> 2) calling cursor.update({id: 23, fname: "Fred"})
> The former seems to match the behavior of the IDBObjectStore.openCursor and
> IDBIndex.openObjectCursor better (i.e. it modifies the cursor.value). The
> latter intuitively seems like it'd be more useful. But to be honest, I
> can't think of any use cases for either. Can anyone else? If not, maybe we
> should just make this unsupported for now?
The only use case I have thought of is wanting to update some set of
entries, where the best way to find these entries is through an index.
For example updating every entry with a specific shipping-id. You can
use IDBIndex.openObjectCursor for this, but that's slower than
IDBIndex.openCursor. So in the rare instance when you can make the
modification without inspecting the existing value (i.e. you only need
to write, read-modify-write), then IDBIndex.openCursor +
IDBCursor.update() would be a perf optimization.
On the other hand, it might be just as quick to call IDBObjectStore.put().
Since the use case if pretty weak (when would you be able to update an
entry without first reading the entry), and that you can seemingly get
the same performance using IDBObjectStore.put(), I would be fine with
making this unsupported.
As for IDBCursor.delete(), I can see a somewhat stronger use case
there. For example removing all entries with a specific shipping-id or
some such. If you can determine which entries should be removed purely
on the information in the index, then using IDBIndex.openCursor is
definitely faster than IDBIndex.openObjectCursor. So on one hand it
would be nice to allow people to use that. On the other hand, I
suspect you can get the same performance using IDBObjectStore.delete()
and we might want to be consistent with IDBCursor.update().
In this case I'm actually leaning towards allowing IDBCursor.delete(),
but I could go either way.
/ Jonas
Received on Wednesday, 15 September 2010 21:46:04 UTC