I didn't see attached archive the first time, I 've visited the link.
Now, I see it. It seems to me better to include example when Composite key class uses other composite key as parameter.
Also I've explored such thing:
Entity Class A has Composite key A.PK
A.PK has fields: int, int.
Entity Class B has Composite key B.PK
B.PK has fields: int, A.PK
Entity Class C has Composite key C.PK
C.PK has fields: int, B.PK.
Entites A and B will be properly presented in DB tables.
But Entity C has Composite key (C.PK), based on other composite key (B.PK), which is also based on composite key (A.PK).
Entity C will not be presented. I don't know why. Maybe I make some mistakes, maybe the reason is other.
Entity A will have 2 key fields (int, int)
Entity B will have 3 key fields (approximate limit) (int,int form A.PK and own int)
Entity C will have 5 key fields (int,int from A.PK, int,int from B.PK and own int)
Databases works badly when table has more than 3 key fields.
Pinaki Poddar wrote:
Hi,
The cited example [1] does demonstrate an use case where a second-level derived identity I2 (PageId) is composed of another identity I1 (BookId) which itself is a non-primitive or non-String composite key derived from another entity (Library).
If you have access to OpenJPA source tree then you can find the test cases of similar usage with Page/Book/Library entity classes.