cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <>
Subject Re: setter for toMany in generated classes
Date Mon, 26 Jan 2015 01:23:06 GMT
I am also of the opinion that this should be a per-user customization
that someone can make rather than something that should be provided
out of the box.  I don't think this should be part of Cayenne.

But since I'm not an active committer any more, I wasn't going to be
the first to say so.

On Sun, Jan 25, 2015 at 7:13 AM, Andrus Adamchik <> wrote:
>> 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