OK ic, thanks for the clarification. I still think it is a bug, because if I wanted to search by the super class I would have specified that. If you specify class x then how hard is it to get that right, having to specify this using a parameter that is defaulting to false just doesn't make any sense to me.
Anyway thanks for the clarification. Chris -----Original Message----- From: Pinaki Poddar [mailto:[email protected]] Sent: Wednesday, 26 May 2010 3:00 AM To: [email protected] Subject: RE: OpenJPA confusing classes I was not talking about toString() of users' persistent classes. It is about the internal mechanics of OpenJPA encodes/decodes a persistent identity with its type information. When an application does String xid = "123ABC"; X x = em.find(X.class, id); Under certain conditions, OpenJPA internally constructs an "id" Object xid (that is not of type String) using the type info (i.e. X.class) and the stringfid id value (i.e the String value "123ABC"). xid encodes both the type and key value. And the xid instance is the key for any subsequent lookup in OpenJPA internal caches etc. For the reported case, the process that encodes X.class + "123ABC" into xid was confused to lose the type information of the actual class and replaced it with the superclass. Compatibility.UseStrictIdentityValue helped to resolve that confusion. ----- Pinaki -- View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-confusing-classes-tp5094249p5099 457.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
