On 7/31/07, Jan Lendholt <[EMAIL PROTECTED]> 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
