> 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
