Re: [IndexedDB] Cursors and modifications

On Jul 16, 2010, at 5:47 AM, Pablo Castro wrote:

> 
> From: Jonas Sicking [mailto:jonas@sicking.cc] 
> Sent: Thursday, July 15, 2010 11:59 AM
> 
> 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
>>> be.
>>> 
>>> 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.
> 
> Yep, I agree with this, a change happened "for sure" when you see the success callback. Before that you may or may not observe the change if you do a get or open a cursor to look at the record.
> 
>>> 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.
> 
> I hear you on the perf implications, but I'm worried that non-sequential order for callbacks will be completely non-intuitive for users. In particular, if you're changing things as you scan a cursor, if then you cursor through the changes you're not sure if you'll see the changes or not (because the callback is the only "definitive" point where the change is visible. That seems quite problematic...

One use case that is interesting is simultaneously walking over two different cursors, e.g., to process some compound join. In that case, the application determines how fast it wants to move on any of a number of open cursors. Would this be supported with this behavior?

Nikunj

Received on Thursday, 22 July 2010 16:56:40 UTC