Seems there's a regression in custom id classes and bidirectional many-
to-one relationships. Haven't tried many-to-many but I suspect it
exists there as well.
It seems that the order of parameters filled into the SQLBuffer are
getting mixed. When the owning side's collection is loaded the sql is
correctly generated with the foreign keys in the where clause lining
up to the sql perfectly, but the there seems to be a second pass where
the parameter values are collected in what *appears* to be
alphabetical order. When setParameters(..) is called the orders of
the params are not guaranteed to match and can result in an invalid
select statement.
More details here: https://issues.apache.org/jira/browse/OPENJPA-872
Just a note, I've taken the liberty to mark it as "blocker" as this
regression is causing a small set of TCK failures which is affecting
the pending Geronimo 2.1.4 and 2.2 releases. The area isn't actually
the JPA side of the TCK but rather the EJB/CMP20 side (i.e. the
OpenEJB CMP/JPA bridge).
I've included a small test case which replicates the issue. It uses a
container managed entity manager, but could easily be reworked for
standalone jpa -- was just easier to get something running this way.
-David
