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!
