FAQ
I have a nested DataContext:

DataContext childContext = parentContext.createChildDataContext();

I have a Master and 3 Details (1-to-many) in the parent DC (in a
committed state), and pull the Master into the nested DC using
localObject(). If I then do the following:

Master childMaster = (Master)
childContext.localObject(parentMaster.getObjectId(), null);

Detail d = (Detail) childContext.newObject(Detail.class);
d.setXXXXXXXX(...); // do sets
childMaster.addToDetails(d);

childContext.commitChangesToParent();

childContext.deleteObject(d);
childMaster.removeFromDetails(d);
childContext.commitChangesToParent();

I get an exception on the last commitChangesToParent():

Exception in thread "main" org.apache.cayenne.CayenneRuntimeException:
[v.3.0M1 Jul 16 2007 22:25:33] Can't build a query for temporary id:
<ObjectId:Detail, TEMP:000004B078EB2838>

Is this to be expected? If I change commitChangesToParent() to
commitChanges() it works ...

Thanks,

/dev/mrg

Search Discussions

  • Andrus Adamchik at Oct 4, 2007 at 4:38 pm
    Looks like a bug. In any event probably worth investigating.

    Andrus

    On Oct 4, 2007, at 7:06 PM, Michael Gentry wrote:

    I have a nested DataContext:

    DataContext childContext = parentContext.createChildDataContext();

    I have a Master and 3 Details (1-to-many) in the parent DC (in a
    committed state), and pull the Master into the nested DC using
    localObject(). If I then do the following:

    Master childMaster = (Master)
    childContext.localObject(parentMaster.getObjectId(), null);

    Detail d = (Detail) childContext.newObject(Detail.class);
    d.setXXXXXXXX(...); // do sets
    childMaster.addToDetails(d);

    childContext.commitChangesToParent();

    childContext.deleteObject(d);
    childMaster.removeFromDetails(d);
    childContext.commitChangesToParent();

    I get an exception on the last commitChangesToParent():

    Exception in thread "main" org.apache.cayenne.CayenneRuntimeException:
    [v.3.0M1 Jul 16 2007 22:25:33] Can't build a query for temporary id:
    <ObjectId:Detail, TEMP:000004B078EB2838>

    Is this to be expected? If I change commitChangesToParent() to
    commitChanges() it works ...

    Thanks,

    /dev/mrg
  • Michael Gentry at Oct 4, 2007 at 6:04 pm
    Well, I have a little bit of a test harness that produces the
    exception. I'll try to package it up later if anyone else would like
    to look at it.

    Thanks,

    /dev/mrg

    On 10/4/07, Andrus Adamchik wrote:
    Looks like a bug. In any event probably worth investigating.

    Andrus

    On Oct 4, 2007, at 7:06 PM, Michael Gentry wrote:

    I have a nested DataContext:

    DataContext childContext = parentContext.createChildDataContext();

    I have a Master and 3 Details (1-to-many) in the parent DC (in a
    committed state), and pull the Master into the nested DC using
    localObject(). If I then do the following:

    Master childMaster = (Master)
    childContext.localObject(parentMaster.getObjectId(), null);

    Detail d = (Detail) childContext.newObject(Detail.class);
    d.setXXXXXXXX(...); // do sets
    childMaster.addToDetails(d);

    childContext.commitChangesToParent();

    childContext.deleteObject(d);
    childMaster.removeFromDetails(d);
    childContext.commitChangesToParent();

    I get an exception on the last commitChangesToParent():

    Exception in thread "main" org.apache.cayenne.CayenneRuntimeException:
    [v.3.0M1 Jul 16 2007 22:25:33] Can't build a query for temporary id:
    <ObjectId:Detail, TEMP:000004B078EB2838>

    Is this to be expected? If I change commitChangesToParent() to
    commitChanges() it works ...

    Thanks,

    /dev/mrg
  • Michael Gentry at Oct 4, 2007 at 6:57 pm
    I'm not sure if it matters, but in the test program I only pulled the
    Master object into the child DC. Is it important to pull the Detail
    objects into the child DC as well? For some reason, I was under the
    impression they would get pulled into the child DC automatically, but
    perhaps I am mistaken?

    Thanks,

    /dev/mrg
  • Andrus Adamchik at Oct 5, 2007 at 10:24 am
    I committed a fix. Per my Jira comment there is a "correct" way to go
    about it that requires a bit of object lifecycle redesign, but my
    fairly straightforward workaround should work for this particular case.

    Andrus

    On Oct 4, 2007, at 9:57 PM, Michael Gentry wrote:

    I'm not sure if it matters, but in the test program I only pulled the
    Master object into the child DC. Is it important to pull the Detail
    objects into the child DC as well? For some reason, I was under the
    impression they would get pulled into the child DC automatically, but
    perhaps I am mistaken?

    Thanks,

    /dev/mrg
  • Michael Gentry at Oct 5, 2007 at 12:58 pm
    So just changing the order of operations was the trick? Perhaps it
    should just be documented that you remove from relationships before
    you delete from the context?

    I think the main reason I did it in the order I did was because, in my
    test, right after that I had:

    childContext.deleteObject((Detail) childM.getDetails().get(0));
    childM.removeFromDetails((Detail) childM.getDetails().get(0));

    If I had reversed the order, I'd have needed a variable to store
    childM.getDetails().get(0). How is that for lazy? :-)

    /dev/mrg

    On 10/5/07, Andrus Adamchik wrote:
    I committed a fix. Per my Jira comment there is a "correct" way to go
    about it that requires a bit of object lifecycle redesign, but my
    fairly straightforward workaround should work for this particular case.

    Andrus

    On Oct 4, 2007, at 9:57 PM, Michael Gentry wrote:

    I'm not sure if it matters, but in the test program I only pulled the
    Master object into the child DC. Is it important to pull the Detail
    objects into the child DC as well? For some reason, I was under the
    impression they would get pulled into the child DC automatically, but
    perhaps I am mistaken?

    Thanks,

    /dev/mrg
  • Andrus Adamchik at Oct 5, 2007 at 1:31 pm

    So just changing the order of operations was the trick? Perhaps it
    should just be documented that you remove from relationships before
    you delete from the context?
    I'd say Cayenne should handle that. When I encounter quirks like that
    in other frameworks, I tend to jump to quick conclusions about the
    quality of a given framework. So this is one of those small things we
    should fix to ensure that the user impression of Cayenne is always
    "it just works" :-)

    Andrus


    On Oct 5, 2007, at 3:58 PM, Michael Gentry wrote:
    So just changing the order of operations was the trick? Perhaps it
    should just be documented that you remove from relationships before
    you delete from the context?

    I think the main reason I did it in the order I did was because, in my
    test, right after that I had:

    childContext.deleteObject((Detail) childM.getDetails().get(0));
    childM.removeFromDetails((Detail) childM.getDetails().get(0));

    If I had reversed the order, I'd have needed a variable to store
    childM.getDetails().get(0). How is that for lazy? :-)

    /dev/mrg

    On 10/5/07, Andrus Adamchik wrote:
    I committed a fix. Per my Jira comment there is a "correct" way to go
    about it that requires a bit of object lifecycle redesign, but my
    fairly straightforward workaround should work for this particular
    case.

    Andrus

    On Oct 4, 2007, at 9:57 PM, Michael Gentry wrote:

    I'm not sure if it matters, but in the test program I only pulled
    the
    Master object into the child DC. Is it important to pull the Detail
    objects into the child DC as well? For some reason, I was under the
    impression they would get pulled into the child DC automatically,
    but
    perhaps I am mistaken?

    Thanks,

    /dev/mrg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedOct 4, '07 at 4:06p
activeOct 5, '07 at 1:31p
posts7
users2
websitecayenne.apache.org

2 users in discussion

Michael Gentry: 4 posts Andrus Adamchik: 3 posts

People

Translate

site design / logo © 2022 Grokbase