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

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