On Wed, Sep 15, 2010 at 10:45 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> 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 <jor...@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. > Wait a sec. What are the use cases for non-object cursors anyway? They made perfect sense back when we allowed explicit index management, but now they kind of seem like a premature optimization or possibly even dead weight. Maybe we should just remove them altogether? J