I'm migrating an old application using xdoclet to Hibernate 4 with annotations. I'm having a problem translating the "hibernate.properties" xdoclet tag (which generates as <properties unique="false".../>;
in .hbm.xml
) to equivalent annotations. Based on Hibernate's JIRA, it looks like a @Properties
annotation was never created when Hibernate annotations were created, and is still being mulled over as a possible enhancement in Hibernate 5.
Here's how the application is using <properties>
. A properties group is set up as follows:
/**
* @hibernate.class table="ENTITY_A" dynamic-update="true" dynamic-insert="true"
* @hibernate.properties name="b_plus_c_group"
*/
public class ClassA {
private ClassB b;
private ClassC c;
...
/**
* @hibernate.many-to-one
* column="COL_B"
* class="com.acme.ClassB"
* cascade="none"
* properties-name="b_plus_c_group"
*/
ClassB getB() {
return b;
}
/**
* @hibernate.many-to-one
* column="COL_C"
* class="com.acme.ClassC"
* cascade="none"
* properties-name="b_plus_c_group"
*/
ClassC getC() {
return c;
}
}
The "b_plus_c_group" is then used in another entity to express a join to ClassA using b and c as keys:
/**
* @hibernate.many-to-one
* property-ref="b_plus_c_group"
* insert="false"
* update="false"
* cascade="all"
* fetch = "join"
* class="com.acme.ClassA"
* @hibernate.formula value="COL_B"
* @hibernate.formula value="COL_C"
*/
ClassA getA() {
return a;
}
Some business logic also references the properties group when constructing a Criteria query:
Criteria criteria = session.createCriteria(ClassA.class, "a");
criteria
.createAlias("b_plus_c_group", "bpc")
.createAlias("bpc.b", "b")
.createAlias("bpc.c", "c")
.add(Restrictions.eq("c.keyField", keyForC))
.setProjection(
Projections.projectionList()
.add(Projections.property("a.description"))
.add(Projections.property("b.description")));
(Note: unfortunately, a test environment does not exist for the xdoclet-based implementation currently in production, so I can't easily run scenarios to see how these queries actually behave. At this point I'm dependent on manual observation.)
My summary of the usage here is: we have a pair of properties "b" and "c" that together form a non-unique key for A (unique="false" is the default). So we give that pair of properties the name "b_plus_c_group" and use it:
- as the key for a many-to-one relation to A from another entity
- but how can a non-unique pair of keys dependably yield the single result required by a many-to-one? And what additional role is played by the inclusion of formulas consisting of COL_B and COL_C?
- as a way to get the fields in the group to express a Restriction and a Projection for a query.
- but can't these be expressed as simply "a.b" and "a.c"?
So I have two usages that look faulty to me (but I could be missing something), and no way to just translate those over to annotations verbatim.
Can anyone clarify the expected behavior and offer a way to express as annotations?