[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4493?page=c... ] Paul Benedict commented on HHH-4493: ------------------------------------ JPA 2.0 introduced @MapKeyJoinColumn and @MapKeyJoinColumns, which I think is very similar to what is trying to be done here. There is @JoinColumn(s) for basic columns, @MapKeyJoinColumn(s) when columns key a map, and I propose re-factoring to allow a @FormulaJoinColumn(s) for formulas. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4493?page=c... ] Paul Benedict commented on HHH-4493: ------------------------------------ My reading was here: http://docs.sun.com/app/docs/doc/820-7627/bnbpy?a=view My understanding of designing extensions is not to supplant (i.e., uproot) the uses of the standard. Thus, if it is valid to use @JoinColumn(s) today, it shouldn't have to be wrapped or replaced to extend the feature -- but allow additions on top. That's why I think this alternative is more fluent. Also I think there is an argument here for portability. If entities do exist that are JPA compliant, but also take advantage of Hibernate features whenever Hibernate is the persistence provider, using a wrapper would hinder the possibility. I prefer a graceful degradation where possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira