On Jul 22, 2010, at 11:29 AM, Jonas Sicking wrote: > On Thu, Jul 22, 2010 at 3:49 AM, Nikunj Mehta <[email protected]> wrote: >> >> On Jul 16, 2010, at 5:47 AM, Pablo Castro wrote: >> >>> >>> From: Jonas Sicking [mailto:[email protected]] >>> Sent: Thursday, July 15, 2010 11:59 AM >>> >>> On Thu, Jul 15, 2010 at 11:02 AM, Pablo Castro >>> <[email protected]> wrote: >>>>>> >>>>>> From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy >>>>>> Orlow >>>>>> Sent: Thursday, July 15, 2010 2:04 AM >>>>>> >>>>>> On Thu, Jul 15, 2010 at 2:44 AM, Jonas Sicking <[email protected]> wrote: >>>>>> On Wed, Jul 14, 2010 at 6:20 PM, Pablo Castro >>>>>> <[email protected]> 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? > > Yes. cursor.continue() calls still execute in the order they are > called, so you can alternate walking two separate cursors without any > changes in callback order.
Excellent
