- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 15 Sep 2010 16:55:28 +0100
- To: public-webapps WG <public-webapps@w3.org>
- Message-ID: <AANLkTin1TVzH2NrMwgTWGXLzqtKqpSNufPdkTg09apmU@mail.gmail.com>
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). 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. 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? Btw, http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-update probably needs to include some other errors as well since we need to return something when a constraint can't be met with the new value. Also, I'll note that while writing this code, I've gotten confused a couple times about what is the key and what is the value for Index cursors. I'm a bit concerned web developers will as well. J
Received on Wednesday, 15 September 2010 15:56:25 UTC