Ideally a isSynthetic() check is best. It's what I considered first. However I tend to stay away from changing these mapping classes as historically I have sometimes screwed up Max and other mapping package consumers in ways I totally did not expect.
Max, do you see any potential issue with this? On 03/30/2010 04:55 AM, Emmanuel Bernard wrote: > Your reading is correct. > We create a synthetic property that we use to populate the *-to-one > property-ref element. > The reason behind it is that JPA is more flexible than Core and allow to > reference columns instead of properties. This could lead to reference columns > coming from different properties, in different order than the one described > in the "referenced property" etc etc. > > To work around that, I create a synthetic property. Note that the particular > case of http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 > could be optimized as we don't need the synthetic property ( there is a > //todo in the code about that :) ). > > You're right, we probably should create a SyntheticProperty type (subclassing > Property like BackRef) and add a isSynthetic getter on the Property contract. > If we are good with that, I can implement that fairly quickly. > > On 30 mars 2010, at 03:42, Steve Ebersole wrote: > >> Little more info. The generated property is coming from >> BinderHelper.createSyntheticPropertyReference as called from >> org.hibernate.cfg.ToOneFkSecondPass#doSecondPass >> >> The mappings in question here are: >> >> public class Company { >> @Id >> @Column(name = "entity_id") >> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = >> "SEQ_STORE") >> private Long id = null; >> >> @Column(name = "id", nullable = false, unique = true, updatable = >> false) >> private Long companyId = null; >> >> ... >> } >> >> public class Person { >> ... >> @ManyToOne(fetch = FetchType.LAZY) >> @JoinColumn(name = "relation_id", referencedColumnName = "id") >> private Company company = null; >> } >> >> The binder code is creating a synthetic component property on Company >> presumably (?) to act as the FK target for this ManyToOne. Is that the >> correct reading of what is going on? I have no clue what is a valid use >> case for doing this so I am largely making an educated guess at what is >> going on here. >> >> Lets assume that this "synthetic property is needed"... In that case >> I'd then say that it seems to me we need to create it in such a manner >> that it is distinguishable from a "real" property so that it can later >> be excluded during the @StaticMetamodel binding process (very much like >> we do already for back-refs). >> >> To that end I committed a change that resolved this for the test case >> submitted by Andreas to HHH-4870. It caused no regressions. >> >> On related topic, anyone have thoughts on good way to test this >> @StaticMetamodel binding code? >> >> >> On 03/29/2010 12:28 PM, Steve Ebersole wrote: >>> In regards to >>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870 I >>> have taken a look at the test case. The issue comes from a property that >>> annotation-binder is generating that I have no idea why it is. >>> Specifically, take a look at the comment: >>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4870?focusedCommentId=35997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_35997 >>> >>> >>> Anyone have any ideas? >>> >>> >> >> -- >> st...@hibernate.org >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
