Thanks, David, for the heads up and the JIRA issue. The first thought that comes to mind is the sql caching support that was put into 1.2.0. As a quick test, would you mind running with the following property? If turning off the sql cache doesn't help your condition, then we've uncovered a different area of concern. Thanks.
openjpa.jdbc.QuerySQLCache = false Kevin On Mon, Jan 26, 2009 at 1:33 AM, David Blevins <[email protected]>wrote: > 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 > > > >
