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. > > > -- View this message in context: http://n2.nabble.com/Enterprise-JavaBeans---HowTo%3A-construct-Composite-key-using-other-composite-key--tp788926p791523.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
