| In order to fix this issue we are ultimately going to need to redesign how the IdMapper and implementations work. Lets take the following example:
@Entity
@IdClass(SomeOtherEntityCId.class)
public class SomeOtherEntityC {
@Id
@ManyToOne
private SomeOtherEntityA a;
@Id
@ManyToOne
private SomeOtherEntityB b;
}
class SomeOtherEntityCId implements Serializable {
private SomeOtherEntityA a;
private SomeOtherEntityB b;
}
This effectively would generate an XML composite-id mapping of:
<composite-id name="originalId">
<key-many-to-one name="a" class="org.hibernate.envers.test.integration.ids.idclass.SomeOtherEntityA" foreign-key="none" />
<key-many-to-one name="b" class="org.hibernate.envers.test.integration.ids.idclass.SomeOtherEntityB" foreign-key="none" />
<key-many-to-one type="integer" class="org.hibernate.envers.enhanced.SequenceIdRevisionEntity" name="REV" />
</composite-id>
As seen here, the composite-id references the concrete instance types of the association. When done this way, Envers doesn't treat this mapping any differently than it would if it were an @EmbeddedId despite the fact the mapping uses an @IdClass references container. The problem arises with the following scenario:
@Entity
@IdClass(SomeOtherEntityCId.class)
public class SomeOtherEntityC {
@Id
@ManyToOne
private SomeOtherEntityA a;
@Id
@ManyToOne
private SomeOtherEntityB b;
}
class SomeOtherEntityCId implements Serializable {
private Integer a;
private Integer b;
}
Again in this scenario this effectively generates an XML composite-id mapping of:
<composite-id name="originalId">
<key-many-to-one name="a" class="org.hibernate.envers.test.integration.ids.idclass.SomeOtherEntityA" foreign-key="none" />
<key-many-to-one name="b" class="org.hibernate.envers.test.integration.ids.idclass.SomeOtherEntityB" foreign-key="none" />
<key-many-to-one type="integer" class="org.hibernate.envers.enhanced.SequenceIdRevisionEntity" name="REV" />
</composite-id>
The problem arises when the audit event fires Envers is given an identifier of SomeOtherEntityCId type that has numeric primary key values. In order to save the audit entry, we need to come up with a way that allows us to lookup the appropriate association instance based on the supplied primary key or at the very least acquire that reference from the entity itself. Presently with how the methods are defined, this just isn't clearly possible. We'll also need to check on the read-side and make sure during hydration that we handle populating the @Id associations correctly. |
