cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes <>
Subject Re: setter for toMany in generated classes
Date Mon, 26 Jan 2015 18:47:57 GMT
I'm fine with activating the toMany-setter in subclasses manually.

My motivation for introducing the delete parameter was, that your are
not able to the treat orphaned objects with a delete rule. Please
correct me, if its wrong. The delete rule is called only, if you trigger
.delete(). If you just remove your relationship: no entity will be
deleted. I guess this is the deletion question Michael Gentry was
talking about.

Am 25.01.2015 um 13:13 schrieb Andrus Adamchik:
>> On Dec 27, 2014, at 6:07 PM, Johannes <> wrote:
>> Hello, I moved the method to CayenneDataObject. I hope the documentation
>> is more meaningfull now.
>> The superclass.vm contains for every set-able relationship two method
>> which calls the setter in CayenneDataObject. Two methods because a
>> default value for deletion.
>> Would be happy if anybody could review it again at
>> Regards Johannes
> So we are talking about this pull request:
> A question to Cayenne committers and community ... Proposed implementation will require
cleanup, optimization and very thorough testing. But aside from that, do we think a collection
setter is universally useful to a point that all to-many relationships should expose it? 
> Here is my feedback. I am ok with including a to-many collection "sync" operation in
CayenneDataObject, but I am against placing it in default .vm template. This is based on the
assumption that we are dealing with an occasionally, but not universally useful operation.
So e.g. if a user decides he needs this op for Artist.paintings(..) collection, he would simply
create a method in a subclass:
> Artist extends _Artist {
>    void setPaintings(List<Paintings> ps) {
>        setToManyTarget(_Artist.PAINTINGS, ps, true);
>    }
> }
> An ability to extend template behavior with custom per-object code is exactly the reason
we have sub/superclass separation.
> Also I am tentatively -1 on the delete option. I would generally handle it with a proper
delete rule in the model. 
> Thoughts?
> Andrus

View raw message