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

RE: [IndexedDB] Cursors and modifications

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 15 Jul 2010 18:02:17 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
CC: Andrei Popescu <andreip@google.com>, Webapps WG <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E058EF1F36@TK5EX14MBXC124.redmond.corp.microsoft.com>

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. 

Received on Thursday, 15 July 2010 18:02:55 UTC

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