[forge-dev] [Proposal] Helper methods for managing inverse relationships

[Lincoln Baxter, III]

TBH. I am fine with doing this as long as there are unit tests to accompany
it!

~Lincoln

On Tue, Sep 25, 2012 at 2:24 AM, Marius Bogoevici <mariusb at redhat.com>wrote:

> 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 at redhat.com>
> 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 at 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20121008/beb2f675/attachment.html