openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Compatibility.getStrictIdentityValues() == false: Kodo archaeology question
Date Tue, 20 Jul 2010 04:35:00 GMT
Hi,

The default value for Compatibility.getStrictIdentityValues() is false. Does anyone remember
the rationale for this? It looks like this is buried in the (non-public) Kodo codebase.

I just ran into a problem in the following scenario:

> @Entity
> @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
> abstract class Foo {
> 
>     @Id String id;
> }
> 
> @Entity
> class Bar extends Foo { }
> 
> @Entity
> class Baz extens Foo { }


If I do the following:

> em1.getTransaction().begin();
> Bar bar = new Bar();
> bar.id = "aoeu";
> em1.persist(bar);
> em1.getTransaction().commit();
> 
> Baz b = em2.find(Baz.class, "aoeu");

I get a ClassCastException. The problem is that OpenJPA is resolving Baz.class's pk type to
the pk type for Foo and then doing a serial lookup for all Foo entities with a matching ID.
This hits on the Bar table first, and thus returns a Bar, which fails to cast to Baz.

If I toggle StrictIdentityValues to true, the 'right' code in BrokerImpl.newObjectId() is
invoked, and everything works beautifully.

Now, I can imagine that there are other issues with the old OpenJPA behavior, but I know we
put a lot of work into making the intuitive stuff happen in these codepaths. So, I'm trying
to figure out why we ended up introducing StrictIdentityValues. Sadly, looking at the svn
blame output, it looks like this comes from the original Kodo codebase, whose history I don't
have access to anymore. Anyone?

Thanks,

-Patrick

-- 
Patrick Linskey
202 669 5907


Mime
View raw message