Lincoln and I have discussed this on IRC, and whiles this has been deemed a good idea, we're wondering what everyone else thinks. So, thoughts?

I find it very nice ! However, as max pointed out, there are some issues when generating the entities from the DB. And it seems pretty simple to implement it as well. We could add another option to the entity plugin to allow the user to choose if that piece of code should be generated. Is there already a JIRA issue for this ? Best Regards, George Gastaldi On 09/24/2012 11:37 AM, Marius Bogoevici wrote: > All, > > I have a proposal for the persistence plugin, regarding the handling of inverse relationships. > > When working with inverse relationships in Hibernate and JPA, it is a common and encouraged practice to include convenience methods for correctly managing the inverse end of the relationship, so that the entity user would be relieved from the burden of setting each end manually when the relationship. e.g. 'addSubCategory' in > > @Entity > public class SubCategory { > > @ManyToOne > private Category parent; > } > > > @Entity > public class Category { > > @OneToMany(mappedBy = "parent") > private Set<SubCategory> subcategories = new HashSet<SubCategory>(); > > …. > > > public void addSubCategory(SubCategory subcategory) { > this.subcategories.add(subcategory); > subcategory.setParent(this); > } > > } > > or something more elaborate (null checks etc) but to the effect of . This can be combined with returning non-modifiable collections by the getters, etc. but the gist of it is to provide a single operation through which developers will set up the bi-directional relationship, thus preventing the model from becoming inconsistent (or even not persisted correction). > > Essentially this is a quite established good practice, which the ones of us who admit to being old enough to have read Gavin&Christian's book will remember. Now this is a PITA to do manually, but Forge could easily take care of it. > > Lincoln and I have discussed this on IRC, and whiles this has been deemed a good idea, we're wondering what everyone else thinks. So, thoughts? > > Cheers, > Marius > > > _______________________________________________ > forge-dev mailing list > > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -- George Gastaldi | Senior Software Engineer JBoss Forge Team Red Hat _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

I think so. In fairness, this is done mainly to cover the higher-risk situation when the object is added to the collection without being added on the inverse side, which can cause lost updates and other kinds of errors. On 2012-09-24, at 2:08 PM, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: > another aspect is that if the "other" side is lazy then doing this would actually trigger unnecessary loads from the db. > > I guess if users want this they would just use the accessors directly without the helper methods. > > /max > > On 24 Sep 2012, at 18:55, ggastald(a)redhat.com wrote: > >> I find it very nice ! However, as max pointed out, there are some issues when generating the entities from the DB. >> >> And it seems pretty simple to implement it as well. We could add another option to the entity plugin to allow the user to choose if that piece of code should be generated. Is there already a JIRA issue for this ? >> >> Best Regards, >> >> George Gastaldi >> >> On 09/24/2012 11:37 AM, Marius Bogoevici wrote: >>> All, >>> >>> I have a proposal for the persistence plugin, regarding the handling of inverse relationships. >>> >>> When working with inverse relationships in Hibernate and JPA, it is a common and encouraged practice to include convenience methods for correctly managing the inverse end of the relationship, so that the entity user would be relieved from the burden of setting each end manually when the relationship. e.g. 'addSubCategory' in >>> >>> @Entity >>> public class SubCategory { >>> >>> @ManyToOne >>> private Category parent; >>> } >>> >>> >>> @Entity >>> public class Category { >>> >>> @OneToMany(mappedBy = "parent") >>> private Set<SubCategory> subcategories = new HashSet<SubCategory>(); >>> >>> …. >>> >>> >>> public void addSubCategory(SubCategory subcategory) { >>> this.subcategories.add(subcategory); >>> subcategory.setParent(this); >>> } >>> >>> } >>> >>> or something more elaborate (null checks etc) but to the effect of . This can be combined with returning non-modifiable collections by the getters, etc. but the gist of it is to provide a single operation through which developers will set up the bi-directional relationship, thus preventing the model from becoming inconsistent (or even not persisted correction). >>> >>> Essentially this is a quite established good practice, which the ones of us who admit to being old enough to have read Gavin&Christian's book will remember. Now this is a PITA to do manually, but Forge could easily take care of it. >>> >>> Lincoln and I have discussed this on IRC, and whiles this has been deemed a good idea, we're wondering what everyone else thinks. So, thoughts? >>> >>> Cheers, >>> Marius >>> >>> >>> _______________________________________________ >>> forge-dev mailing list >>> >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> -- >> George Gastaldi | Senior Software Engineer >> JBoss Forge Team >> Red Hat >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev