That will work thank you. I assume it will also work in an ROP
environment correct?
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 *
z.trabari..nsysware.com * 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:robert.zeigle..mail.com]
Sent: Saturday, March 07, 2009 4:04 PM
To: use..ayenne.apache.org
Subject: Re: Child commit and rollback question
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 *
> z.trabari..nsysware.com * 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:robert.zeigle..mail.com]
> Sent: Saturday, March 07, 2009 2:29 PM
> To: use..ayenne.apache.org
> 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 *
>> z.trabari..nsysware.com <mailto:%20%20z.trabaris@insysware.com> *
>> 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.
>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Sun Mar 08 2009 - 06:44:23 EDT