On 7/31/07, Jan Lendholt <jlendhol..otmail.com> 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 another,
> e.g. method, to use.
> Now the object is already registered in the "root" context and I would like
> to transer it to a child DataContext. That sounds to me a bit intensive on
> 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:
http://cayenne.apache.org/doc20/moving-objects-between-contexts.html
Something like:
nestedContext.localObject(objectToPullIntoNestedContext.getObjectId(), null)
> Aaaand If i get the object form Context A and put it in nestedContext B, do
> 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 temporarily
> 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 consistent.
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.
/dev/mrg
This archive was generated by hypermail 2.0.0 : Tue Jul 31 2007 - 12:10:51 EDT