W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [Bug 11257] New: Should IDBCursor.update be able to create a new entry?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 11 Nov 2010 13:11:12 -0800
Message-ID: <AANLkTi=08sdrpMW5XYLWUfzfM0dwwMp8zB1EcZ8FXMQ9@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: public-webapps@w3.org
On Thu, Nov 11, 2010 at 11:51 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Nov 11, 2010 at 8:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Nov 11, 2010 at 5:11 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > On Mon, Nov 8, 2010 at 2:12 PM, <bugzilla@jessica.w3.org> 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: dave.null@w3.org
>> >>        ReportedBy: jonas@sicking.cc
>> >>         QAContact: member-webapi-cvs@w3.org
>> >>                CC: mike@w3.org, public-webapps@w3.org
>> >>
>> >>
>> >> 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.

But I still think that .update and .delete are useful and logical API
which has very little implementation cost.

/ Jonas
Received on Thursday, 11 November 2010 21:12:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT