In our data model, we have a set of three tables:



Using a JOINED inheritance strategy, the entities look like:



FOO_ID is a unique number across all three tables so the above code works fine in a single version/language situation. However, when introducing a new version, the flaw of this approach becomes apparent, UPDATE/DELETE lacks “WHERE FOO_REF.VERSION_ID=?” and SELECT lacks the proper INNER JOIN syntax (SELECT . . . FROM FOO_VALUES T1 INNER JOIN FOO_REF T2 ON T1.FOO_ID = T2.FOO_ID AND T1.VERSION_ID = T2.VERSION_ID . . .).

I cannot supply @IdClass in the subclasses (cannot have multiple IDs in the hierarchy). And unfortunately as you move from the subs to the super, the number of key columns goes down, not up, so we have to use the least common denominator on FooKey (fooId).

Is there a way to remedy this situation other than adding the other primary key columns to the other tables? Does the above scenario force us to move to a SINGLE_TABLE inheritance strategy (which would allow us to have an @IdClass/@EmbeddedId for each table with a composite key)?

Thanks.

(Note: related to forum post http://forum.hibernate.org/viewtopic.php?t=967119 - reviewed but did not see a solution other than to modify the physical data model)