+1, Craig. On Tue, May 25, 2010 at 12:33 PM, Craig L Russell <[email protected]>wrote:
> IMHO this is an OpenJPA bug. > > OpenJPA should never use an identity object (type plus key) internally as a > cache key that does not have the exact type. > > If OpenJPA internally constructs an identity object (e,g, for find) that > contains a possible supertype plus key and uses that to find an instance, > that's ok, but the actual identity object with the actual type and key > should always be used for cache keys. > > The fact that Compatibility.UseStrictIdentityValue helped this case, should > make fixing the bug easier. > > Craig > > > On May 25, 2010, at 10:00 AM, Pinaki Poddar wrote: > > >> 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-tp5094249p5099457.html >> Sent from the OpenJPA Users mailing list archive at Nabble.com. >> > > Craig L Russell > Architect, Oracle > http://db.apache.org/jdo > 408 276-5638 mailto:[email protected] > P.S. A good JDO? O, Gasp! > >
