cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: setter for toMany in generated classes
Date Mon, 26 Jan 2015 14:19:40 GMT
In a few of our projects I created a custom template that added a to-many
setter, but ours threw an exception if you called it on an already
populated relationship.  This made sense for our domain, as we were doing
massive XML->Java (Cayenne objects) and wanted to be sure the
transformation tool we were using was not calling the setter multiple times
(which would indicate a problem in our mappings/etc).  When I'm actually
managing the relationships, I tend to prefer doing the adds/removes/deletes
explicitly, but that's just my preference.

I know other times we've had to sync from an external data source which
required loading the Cayenne objects, loading the external data, and
figuring out what needed to be inserted/deleted.  This always ended up
being more trouble that you'd think and perhaps having sync operation on
the to-many setter would've been helpful, but you still have the deletion
question to handle, too.  I suppose this could be another parameter.


On Sun, Jan 25, 2015 at 7:13 AM, Andrus Adamchik <>

> > 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.
> Thoughts?
> Andrus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message