Marshall, I am assuming that the new multi update is actually a single txn. What you need to do next it make sure you take a look at all the processors.
Sync is one where this new txn will need to be logged and then Final is one where the Datatree needs to be updated to reflect all the updates. Its better to keep the discusson on the jira so that any else interested can look at it as well (also for record sake)! Thanks mahadev On 4/21/11 9:42 AM, "Ted Dunning" <[email protected]> wrote: > I am adding the dev list. > > Mahadev, > > Can you help with a pointer here? > > On Thu, Apr 21, 2011 at 9:15 AM, Marshall McMullen > <[email protected]> wrote: >> I've finished the necessary work inside PrepRequestProcessor.java to deal >> with multi-ops. Where is the next layer of this that I need to start working >> on? I'm guessing it's perhaps in one of SyncRequestProcessor, >> FinalRequestProcessor, ZKDatabase or DataTree ? I'll start looking around >> but any guidance is appreciated. >> Thanks!! >> >> ________________________________ >> >> Yep, I discovered that vital piece of info after I emailed this out earlier. >> Glad to see I'm on the right track :-). >> >> ________________________________ >> >> I think you'll need to validate against the changerecord info as well. Call >> getRecordForPath after you've added a changerecord for the create command. >> Assuming like ted said ordering is maintained, which it should be. Is that >> not working? >> >> C >> >> On Apr 20, 2011 4:50 PM, "Marshall McMullen" <[email protected]> wrote: >>> I've been pursuing Camille's suggestion of modifying PrepRequestProcessor >>> to validate all of the ops inside the MultiTransactionRecord. It essentially >>> calls pRequest to ensure validity of the given request. It works perfectly >>> on simple cases that don't depend on other ops within the multi transaction >>> having already been committed. For example, if you have an empty database >>> and submit a multi transaction that contains: >>> >>> create "foo" ... >>> delete "foo" ... >>> >>> Then the validation of the delete on "foo" fails as that op hasn't been >>> committed yet. >>> >>> I'm missing something important here.... anyone want to offer some >>> guidance on how this should be handled? >>> >>> Thanks very much, >>> Marshall >>> >>> ----- Original Message ----- >>> >>>> I would start in preprequestprocessor. Add a case for multi-resp and >>>> validate all of the ops contained therein. >>>> Will look more tonight to flesh out other steps, but that should >>>> hopefully be enough to start. Be sure to think about unit testing >>>> this... we don't seem to have one for prequest at the moment but it >>>> seems totally doable to me. >>>> C >>> >>>> On Apr 19, 2011 1:58 PM, "Marshall McMullen" < [email protected] >>>>> wrote: >> >> >> >
