Not necessarily. When you commit the changes, the differences in
object graphs will be propagated (within the same jvm; you can
propagate to external jvms via jms, as well).
So, for example:
Given artist and painting tables, with a one to many from artist to
painting, the following test (asserts are testng style) passes:
ObjectContext oc = DataContext.createDataContext();
Artist a = oc.newObject(Artist.class);
a.setName("blah");
Painting p = oc.newObject(Painting.class);
p.setArtist(a);
p.setTitle("blah painting");
p.setPrice(25.00);
oc.commitChanges();
assertEquals(p.getArtist(),a);
assertEquals(a.getPaintingList().size(),1);
DataContext oc2 = DataContext.createDataContext();
Painting p2 = (Painting) oc2.localObject(p.getObjectId(), p);
oc2.deleteObject(p2);
oc2.commitChanges();
//quick and dirty way to give enough time for the propagation
to take place, b/c this happens in a background thread.
//w/out this, multi-core machines, especially, will tend to
fail b/c we'll reach the assertion before the propagation is finished.
Thread.sleep(10);//containing method throws InterruptedException
assertTrue(a.getPaintingList().isEmpty());
That is, the painting list of artist a, in ObjectContext oc was
updated to reflect the fact that the painting was deleted, even though
the delete occurred in oc2.
There is /some/ minor difference in p and p2: p2 will have a
persistence state of "DELETED" at this point, whereas p will now be
"TRANSIENT". But the object relationships are still properly handled.
Cheers,
Robert
On Mar 7, 2009, at 3/72:16 PM , Zissis Trabaris wrote:
If I do that them I lose the Cayenne relationship management do I not?
i.e.; Nullifying parent relationship on delete etc.
Zissis Trabaris * Chief Technology Officer * INSYSWARE * 3235 West
River
Road, Grand Island, New York, 14072, USA
Mobile (716) 930-5654 * Office (518) 636-4118 * Fax (716) 625-1305 *
[email protected] * www.insysware.com
CONFIDENTIALITY: This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited. If you received this email in error,
please notify the sender and delete this email from your system. Thank
you.
-----Original Message-----
From: Robert Zeigler [mailto:[email protected]]
Sent: Saturday, March 07, 2009 2:29 PM
To: [email protected]
Subject: Re: Child commit and rollback question
Context creation is fairly cheap; if you're really looking for
isolation of changes, you could create a new object context and
"localObject" the relevant objects into the new context.
Robert
On Mar 7, 2009, at 3/712:54 PM , Zissis Trabaris wrote:
It might be me not finding this in the documentation but here is the
question anyway. Given table A with a toMany relationship to table B,
it's obvious that when I get all instances of table B they share the
same context as table A. When making changes to a table B instance
and a
table A instance, I would like to be able to commit and rollback ONLY
table B's data. Since commitChanges() from the context's perspective
will commit changes to A and B, is there a way to isolate commits and
rollbacks to just one table? From what I understand, nested contexts
will not do this for me because if B was associated to a nested
context
of A's context, commitToParent() will not commit B's data to the
database until I run commitChanges() on A.
Any help here would be appreciated.
Zissis Trabaris * Chief Technology Officer * INSYSWARE * 3235 West
River
Road, Grand Island, New York, 14072, USA
Mobile (716) 930-5654 * Office (518) 636-4118 * Fax (716) 625-1305 *
[email protected] <mailto:%20%[email protected]> *
www.insysware.com <http://www.insysware.com/>
________________________________
CONFIDENTIALITY: This email (including any attachments) may contain
confidential, proprietary and privileged information, and
unauthorized
disclosure or use is prohibited. If you received this email in error,
please notify the sender and delete this email from your system.
Thank
you.
