In the composite key a table with a composite key can be mapped with multiple properties of the class as identiifer properties. The <composite-id> elements accepts <key-property> this property mapping and <key-many-to-one> mappings as child elements.
<composite-id name="propertyName" class="ClassName" mapped="true|false" access="field|property|ClassName"> node="element-name|." <key-property name="propertyName" type="typename" column="column_name"/> <key-many-to-one name="propertyName class="ClassName" column="column_name"/> ...... </composite-id>
<composite-id> <key-property name="medicareNumber"/> <key-property name="dependent"/> </composite-id>
In the composite key persistent class must override equals() and hashCode() to implement composite identifier equality. It must also implement Serializable. we can found this approach to a persistent object is its own identifier. Here we see the there no convenient "handle" to other than the object itself. the we have to notice this instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key. We call this approach an embedded composite identifier, and discourage it for serious applications.
A second approach is what we call a mapped composite identifier, where the identifier properties named inside the <composite-id> element are duplicated on both the persistent class and a separate identifier class.
<composite-id class="MedicareId" mapped="true"> <key-property name="medicareNumber"/> <key-property name="dependent"/> </composite-id>
Here we see an example for, both the composite identifier class, MedicareId, and the entity class itself have properties named medicareNumber and dependent. The identifier class must override equals() and hashCode() and implement Serializable.
We need to know the main disadvantage of this approach is code duplication.
Below some to the following attributes are used to specify a mapped composite identifier:
1. mapped (optional - defaults to false): indicates that a mapped composite identifier is used, and that the contained property mappings refer to both the entity class and the composite identifier class.
2. class (optional - but required for a mapped composite identifier): the class used as a composite identifier.
3. more convenient approach, where the composite identifier is implemented as a component class in Section 8.4, “Components as composite identifiers”.
The attributes described below apply only to this alternative approach:
1. name (optional - required for this approach): a property of component type that holds the composite identifier. Please see chapter 9 for more information.
2. access (optional - defaults to property): the strategy Hibernate uses for accessing the property value.
3. class (optional - defaults to the property type determined by reflection): the component class used as a composite identifier. Please see the next section for more information.
4. The third approach, an identifier component, is recommended for almost all applications.