----- Original Message ----- From: "Matthias Bohlen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 26, 2004 12:59 PM
Subject: [Andromda-user] Hibernate, inverse=true, and components
Hi all,
the Jira issue HIB-2 requests that the inverse=true attribute should be supported. Yesterday and today, I was working on that when I suddenly saw that the template code already tries to support it! This is a quote from HibernateEntity.vsl:
#if ($associationEnd.one2Many) * @hibernate.set * role="$target.name" * lazy="true" #if ($targetType.child) * cascade="delete" * inverse="true" #end ...etc...
I want to discuss an issue with this: The implementation of the "child" attribute has a subtle bug in it (as far as I can see):
public boolean handleIsChild() { return CollectionUtils.find(this.getAssociationEnds(), new Predicate() { public boolean evaluate(Object object) { return ((AssociationEndFacade)object).getOtherEnd() .isComposition(); } }) != null; }
This code says: B is a child if there is at least one class A that has a composition of B objects. Imagine now that a class X composes a lot of Y objects and Z only has a bidirectional association with X, not a composition:
X c----->* Y *------ Z
When generating code for Z.getYs(), Y.isChild() would return true. This is wrong because the association between Y and Z has nothing to do with the composition between X and Y. Z.getYs() should not be influenced by the fact that X has a composition of Ys.
The bug is: isChild() should be an attribute of the association end, not of the class that is connected to the association end.
I'd like to clean this up in the code, while I am at it. What does the rest of the world think about that? Is this really a bug that I see here?
If you sync and get the latest HibernateEntity.vsl, you'll see that it is using the isChild() method on the AssociationEnd (I fixed that a couple days ago). I'd like to keep the isChild()
on the entity, because I use this in other places (i.e. I'd like to know if it is the child of at least one association that's a composition).
More than that: I'd like to make a difference between aggregations and compositions. I'd like to translate aggregations into simple foreign-key relationships whereas one-to-many compositions should be translated with cascade="delete".
I'd like to translate a one-to-one composition into a true Hibernate component, that means, the composed object is mapped into the same table as the parent, field by field. This would require that the users change their models, if they already used compositions to single objects and do not want to compose them into the same table. Has anybody got a problem with that?
What is the benefit of having the one to one table contained within the parent table?
Cheers... Matthias
P.S.: If there are two classes A and B, and A has an attribute of type B, we could also translate this into a Hibernate component (B being a component within A).
---
Matthias Bohlen "Consulting that helps project teams to succeed..."
Internet: http://www.mbohlen.de/ [EMAIL PROTECTED]
Phone: +49 (170) 772 8545
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
