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 <ke...@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" <jor...@chromium.org> wrote: > > On Tue, Feb 1, 2011 at 2:56 PM, Jonas Sicking <jo...@sicking.cc> wrote: > >> >> On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow <jor...@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
