cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
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 <andrus@objectstyle.org> wrote:
>
>> On Dec 27, 2014, at 6:07 PM, Johannes <jotpe.osm@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
>
>

Mime
View raw message