cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: setter for toMany in generated classes
Date Sun, 25 Jan 2015 12:13:42 GMT

> 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. 


View raw message