W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: IndexedDB: updates through cursors on indexes that change the key

From: ben turner <bent.mozilla@gmail.com>
Date: Tue, 1 Feb 2011 16:38:50 -0800
Message-ID: <AANLkTikqi3RxB6s_9p5tH_JAZPhYDM-wTx+-9E7VqFEy@mail.gmail.com>
To: Keean Schupke <keean@fry-it.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>, public-webapps@w3.org, Hans Wennborg <hans@chromium.org>
No, that idea was rejected a while ago. IndexedDB cursors are live, so
any change made during the cursor are visible to the cursor as well as
later queries.

-Ben Turner

On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke <keean@fry-it.com> wrote:
> Surely the cursor should be atomic, representing the instant in time the
> query executed. Any updates or deletes etc would not be visible to the
> cursor, only to later queries. Then you can allow any modifications
> including to keys and indexes.
>
> Cheers,
> Keean
>
> On 2 Feb 2011 00:05, "Jeremy Orlow" <jorlow@chromium.org> wrote:
>
> On Tue, Feb 1, 2011 at 2:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>>
>> On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > On Tue, Feb 1, 2...
>
> Good points (against having it remove the original key if it changes).
> After some more thought: The original idea behind cursor.delete() and
> cursor.update() was that they would basically just be aliases for
> objectStore.delete() and objectStore.put().  Maybe calling .update() with a
> changed primary key should simply have the same behavior as .put().  Thus
> the value corresponding to the original key would be left unmodified and the
> new key would then correspond to the new value.
> I can't think of any examples where the current behavior would get in
> someone's way though.  So I guess maybe we should just leave it as is.  But
> I still hate the idea of it being subtly different from being a straight up
> alias to put.
> J
Received on Wednesday, 2 February 2011 00:39:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC