So this has helped me identify a hole in my current implementation. I need to create a MultiTxn.java to exist alongside CreateTxn.java, DeleteTxn.java, etc. These are all generated somehow and I'm not seeing how that part works. Is this documented somewhere so I can auto generate a new MultiTxn.java? Any tip here would be appreciated.
Thanks! ----- Original Message ----- > Mahadev, > > Thanks for the reply, I appreciate it. This information is super > helpful. > > Yes, the multi is stored in one txn. > > Great suggestion regarding jira... I'll summarize this email chain on > jira > later today. > > Thanks, > Marshall > > ----- Original Message ----- > > 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: > > >> > > >> > > >> > > > > > > > >
