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 <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 > >
signature.asc
Description: OpenPGP digital signature
