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 <and...@objectstyle.org> wrote: > >> On Dec 27, 2014, at 6:07 PM, Johannes <jotpe....@gmail.com> 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 >> https://github.com/jotpe/cayenne/commit/d7251014c9d5cb9396a83cd6e2f16e64af27e4b5 >> >> Regards Johannes > > So we are talking about this pull request: > https://github.com/apache/cayenne/pull/61 . > > 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 > >
