Interesting. It seems like it should have worked without the
cascade... the nullify is what is supposed to do the trick... the
cascade should just affect when you're deleting the parent, so you can
delete the parent and all of the children at the same time. I'd be
curious to see you try the same code with 3.0M6, with the parent's
delete rule unset (ie: no action), and the child's set to nullify. In
any event, glad things are working for you now.
Cheers,
Robert
On Oct 22, 2009, at 10/2212:40 AM , Mark Fraser wrote:
> Thanks Robert. Changing to cascade on the parent did the
> trick....the array members get removed just by calling deleteObjects
> on the data context. Makes sense but this isn't mentioned anywhere
> that I can see in the deleteting objects documentation.
> Mark
>
> Robert Zeigler wrote:
>> Hi Mark,
>>
>> The tips Andrus provided should work, in particular, making sure
>> your delete rules are correct.
>> So the delete rule from for the relationship in the parent entity
>> should (probably) be marked cascade (if the children can't exist w/
>> out the parent; otherwise nullify), and the delete rule for the
>> relationship on the child side should definitely be nullify. I've
>> used this plenty of times and it works. :) So if it's not working
>> for you, maybe something else is going on? Are you using
>> inheritance, by chance?
>>
>> Robert
>>
>> On Oct 22, 2009, at 10/2212:08 AM , Mark Fraser wrote:
>>
>>> >you may want to change delete rule to "Nullify" from many side to
>>> one side of the relationship
>>>
>>> No effect.
>>>
>>> >Otherwise you'd have to explicitly unset the relationship before
>>> deleting an object.
>>>
>>> I'm not sure what you mean by this. Do you mean doing something
>>> like this?:
>>>
>>> this.unsetReverseRelationship("toArtists", this.getToPaintings());
>>>
>>> ..in the tomany (painting) object?
>>>
>>> I tried that and it didn't work (still getting
>>> ConcurrentModificationException).
>>>
>>> I just want to delete all of the objects and have it properly
>>> reflected in the parent's array. It seems like a very everyday
>>> operation. Is it really this difficult?
>>>
>>> Thanks
>>>
>>> Andrus Adamchik wrote:
>>>> Hi Mark,
>>>>
>>>>> However in the modeler the delete rule for both sides of the
>>>>> relationship is "No Action".
>>>>
>>>> you may want to change delete rule to "Nullify" from many side to
>>>> one side of the relationship. Otherwise you'd have to explicitly
>>>> unset the relationship before deleting an object.
>>>>
>>>> Andrus
>>>>
>>>> On Oct 21, 2009, at 10:37 AM, Mark Fraser wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am using Cayenned 2.0.4.
>>>>>
>>>>> What is the proper way to delete the full collection of tomany
>>>>> objects and have the target object's array correctly reflect the
>>>>> deletion?
>>>>>
>>>>> The manual (http://cayenne.apache.org/doc20/deleting-
>>>>> objects.html) says to use dataContext.deleteObjects if you want
>>>>> to delete all objects in the collection.
>>>>> What it does not say is that the target object's array will
>>>>> still contain references to objects that are scheduled for
>>>>> deletion (or have been deleted after committal).
>>>>>
>>>>> I have code like this:
>>>>>
>>>>> System.out.println("paintings: " +
>>>>> artist.getPaintingsArray().size()); // "1"
>>>>> dataContext.deleteObjects(artist.getPaintingsArray());
>>>>> System.out.println("paintings: " +
>>>>> artist.getPaintingsArray().size()); // "1"
>>>>> dataContext.commitChanges();
>>>>> System.out.println("paintings: " +
>>>>> artist.getPaintingsArray().size()); // "1"
>>>>>
>>>>>
>>>>> But if I try to delete the objects myself using an iterator as
>>>>> described on that manual page I get a
>>>>> ConcurrencyModificationException--which is warned about on that
>>>>> page. It says this may result from the object being deleted
>>>>> having a "nullify delete rule". However in the modeler the
>>>>> delete rule for both sides of the relationship is "No Action".
>>>>>
>>>>> I would appreciate if someone could suggest how I am supposed to
>>>>> do this (without switching Cayenne versions).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Thu Oct 22 2009 - 01:50:39 EDT