cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lendholt" <>
Subject Re: Prevent of commit
Date Tue, 31 Jul 2007 16:55:38 GMT
Hey Michael,
that's exatcly the clue we needed. Now it works like a charme.
The only annoying thing is to put the object from context a to context b.
I would prefer something like "detach" object from commit. But that's not 
such a clean way like another context...

Wow.,.. that was a hard day.

Thanks a lot to you guys, you were a great help :-)
Thereofore I'll try to submit the MaxDB Database Adapter to the dev-list 


>From: "Michael Gentry" <>
>Subject: Re: Prevent of commit
>Date: Tue, 31 Jul 2007 12:09:15 -0400
>On 7/31/07, Jan Lendholt <> wrote:
> > Hi Michael, Hi Aristedes,
> >
> > thank you very much for your help.
> >
> > But, still I've got a conceptual problem:
> >
> > I get an object from the "root" DataContext and pass this object to 
> > e.g. method, to use.
> > Now the object is already registered in the "root" context and I would 
> > to transer it to a child DataContext. That sounds to me a bit intensive 
> > the working time spent to create an object and transfer it directly to
> > another context.
>Can you not just fetch the object you need into the nested context
>directly?  You could always use the localObject() method to pull it
>into your nested context:
>Something like:
> > Aaaand If i get the object form Context A and put it in nestedContext B, 
> > a commit - where is the Object then? Is it belonging to Context A, B or
> > both? And if I want to reuse the object of context A which has 
> > been moved to context B to be commited separately, is it synchroniously
> > updated in context A while it was modified in context B?
>It would be in A and B.  And the object in A isn't temporarily moved
>to B, it exists in A and B at the same time, but you want to make
>changes to the one in B.  When you nestedContext.commitChanges() it'll
>update the object in A and in the database, too, unless you call
>nestedContext.commitChangesToParent(), which only pushes the changes
>into A and skips updating the database.
> > For me it's some kind of hard for I really don't know how to handle the
> > different contexts separetaly but keeping the application data 
>You typically create a nested DC when you need to do something that
>you might want to abandon -- a classic example would be a multi-page
>wizard-type process.  At any point in the wizard steps the user can be
>entering data and going to the next page.  This can all be stored in
>the nested DC.  If they cancel, you discard the nested DC -- which
>means your parent DC doesn't get any of the "dirty" objects/changes
>from the nested DC and you don't have to clean anything up or unwind.
>If they finish/save/etc, you commit the changes and the parent DC is
>updated and the database changes are committed.

Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit 
Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! Jetzt gratis downloaden!

View raw message