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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
