W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Cursors and modifications

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 15 Jul 2010 11:58:59 -0700
Message-ID: <AANLkTimEl60hxWYlgn151LFt2Bh42SzVoY4rCV98HAwq@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, Andrei Popescu <andreip@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, Jul 15, 2010 at 11:02 AM, Pablo Castro
<Pablo.Castro@microsoft.com> wrote:
> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow
> Sent: Thursday, July 15, 2010 2:04 AM
> On Thu, Jul 15, 2010 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Jul 14, 2010 at 6:20 PM, Pablo Castro <Pablo.Castro@microsoft.com> wrote:
>>> > If it's accurate, as a side note, for the async API it seems that this makes it more interesting to enforce callback order, so we can more easily explain what we mean by "before".
>>> Indeed.
>>> What do you mean by enforce callback order?  Are you saying that callbacks should be done in the order the requests are made (rather than prioritizing cursor callbacks)?  (That's how I read it, but Jonas' "Indeed" makes me suspect I missed something. :-)
> That's right. If changes are visible as they are made within a transaction, then reordering the callbacks would have a visible effect. In particular if we prioritize the cursor callbacks then you'll tend to see a callback for a cursor move before you see a callback for say an add/modify, and it's not clear at that point whether the add/modify happened already and is visible (but the callback didn't land yet) or if the change hasn't happened yet. If callbacks are in order, you see changes within your transaction strictly in the order that each request is made, avoiding surprises in cursor callbacks.

Oh, I took what you said just as that we need to have a defined
callback order. Not anything in particular what that definition should

Regarding when a modification happens, I think the design should be
that changes logically happen as soon as the 'success' call is fired.
Any success calls after that will see the modified values.

I still think given the quite substantial speedups gained from
prioritizing cursor callbacks, that it's the right thing to do. It
arguably also has some benefits from a practical point of view when it
comes to the very topic we're discussing. If we prioritize cursor
callbacks, that makes it much easier to iterate a set of entries and
update them, without having to worry about those updates messing up
your iterator.

/ Jonas
Received on Thursday, 15 July 2010 18:59:51 UTC

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