| After doing a bit more research, I see why Envers elected to use the map-values as part of the PK. Lets consider the following element collection mapping:
@ElementCollection
private Map<OtherEntity, SomeEnum> theMap;
We would ultimately have a middle table that would look something like this (where fields marked with * represent the PK):
| SomeEntity_id * |
theMap_KEY * |
theMap * |
REV * |
REVTYPE |
Let us assume our owning entity, SomeEntity has a PK of 1 and our SomeEnum has a value-set of A and B. If we insert into the above map OtherEntity with PK of 2 with SomeEnum.A, the table would consist of the following state:
| SomeEntity_id * |
theMap_KEY * |
theMap * |
REV * |
REVTYPE |
| 1 |
2 |
A |
1 |
0 |
In the next transaction, we decide to change the associated SomeEnum value with OtherEntity#2 from A to B.
| SomeEntity_id * |
theMap_KEY * |
theMap * |
REV * |
REVTYPE |
| 1 |
2 |
A |
1 |
0 |
| 1 |
2 |
A |
2 |
2 |
| 1 |
2 |
B |
2 |
1 |
One possible solution here may be to make use of REVTYPE to drive the difference in PK for the two rows rather than theMap map-value. We'll need to make some tests to verify this doesn't break any existing functionality and determine a strategy for how best to implement dealing with the schema change. |
