Re: Prevent of commit

From: Michael Gentry (blacknex..mail.com)
Date: Tue Jul 31 2007 - 12:09:15 EDT

  • Next message: Jan Lendholt: "Re: Prevent of commit"

    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