On Fri, Nov 12, 2010 at 12:11 AM, Jonas Sicking <[email protected]> wrote:
> On Thu, Nov 11, 2010 at 11:51 AM, Jeremy Orlow <[email protected]> > wrote: > > On Thu, Nov 11, 2010 at 8:46 PM, Jonas Sicking <[email protected]> wrote: > >> > >> On Thu, Nov 11, 2010 at 5:11 AM, Jeremy Orlow <[email protected]> > wrote: > >> > On Mon, Nov 8, 2010 at 2:12 PM, <[email protected]> wrote: > >> >> > >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11257 > >> >> > >> >> Summary: Should IDBCursor.update be able to create a new > >> >> entry? > >> >> Product: WebAppsWG > >> >> Version: unspecified > >> >> Platform: PC > >> >> OS/Version: All > >> >> Status: NEW > >> >> Severity: normal > >> >> Priority: P2 > >> >> Component: Indexed Database API > >> >> AssignedTo: [email protected] > >> >> ReportedBy: [email protected] > >> >> QAContact: [email protected] > >> >> CC: [email protected], [email protected] > >> >> > >> >> > >> >> What should happen in the following case: > >> >> > >> >> db.transaction(["foo"]).objectStore("foo").openCursor().onsuccess = > >> >> function(e) > >> >> { > >> >> var cursor = e.result; > >> >> if (!cursor) > >> >> return; > >> >> > >> >> cursor.delete(); > >> >> cursor.update({ id: 1234, value: "Benny" }); > >> >> } > >> >> > >> >> > >> >> This situation can of course arrive in more subtle ways: > >> >> > >> >> os = db.transaction(["foo"]).objectStore("foo"); > >> >> os.openCursor().onsuccess = function(e) { > >> >> var cursor = e.result; > >> >> if (!cursor) > >> >> return; > >> >> > >> >> cursor.update({ id: 1234, value: "Benny" }); > >> >> } > >> >> os.delete(1234); > >> >> > >> >> > >> >> As specified, IDBCursor.update behaves just like IDBObjectStore.put > and > >> >> just > >> >> creates a new entry, but this might be somewhat unexpected behavior. > >> > > >> > Let's just remove update and delete from IDBCursor and be done with > it. > >> > >> The problem is that you can't always get to the key of the objectStore > >> entry to delete/update. Specifically if the objectStore uses > >> out-of-line keys the cursor doesn't expose those. > > > > Why not fix this use case then? I.e. change the cursor to return > .indexKey, > > .primaryKey, .value (or something like that). If we did this, we could > even > > get rid of the different between object cursors and key cursors (which > > overload the .value to mean the primary key, which is quite confusing). > > I would be ok with exposing some new property which exposes the objectstore > key. > And thus get rid of the openKeyCursor and getKey? This would make the spec a bit more complicated (we'd need to have 2 IDBCursor objects, one that inherits from the other), but seems much simpler to use. Shall I file a bug? > But I still think that .update and .delete are useful and logical API > which has very little implementation cost. > I still don't understand why you think low implementation is important at all when talking about these APIs. If something is so insanely complex that implementors would likely not implement it, then I can understand bringing it up, but otherwise I think most people on this list can agree that it should cary _very_ little weight when deciding whether API surface area is worth it. J
