Hi Romain, Nothing is jumping out at me... What "TomEE TCK" are you referring to? We run the JPA 2.0 TCK on every branch (including trunk) and the logs are all clean as of May 21. (It looks like there was a comm problem with communicating with svn last night, so that TCK run didn't kick off.)
You also indicated that the ddl for altering the table constraints didn't get generated with trunk? I'm not aware of any changes in our mapping tool that would have changed that behavior. Are you starting with a fresh database? Or, are you running with the same derby database that was used for the 2.2.0 run? We'll probably need more investigation on what exactly is different between your 2.2.0 test runs and the trunk test runs. Thanks, Kevin On Thu, May 23, 2013 at 7:14 AM, Romain Manni-Bucau <[email protected]>wrote: > Hi guys, > > on TomEE TCKs we were used to get some SQL constraints on a derby database > like: > > ALTER TABLE A ADD CONSTRAINT C FOREIGN KEY (ID) REFERENCES B (ID); > > or the almost same with composed keys (string, string). > > Basically all was green with openjpa 2.2.0 but since openjpa 2.3.0-SNAPSHOT > we get exceptions because of these constraints. Moreover the ddl doesn't > generate them. > > Here the exception: > > Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: DELETE on > table 'X' caused a violation of foreign key constraint 'C' for key > (aaa,bbb). The statement has been rolled back. {prepstmnt 450145810 DELETE > FROM X WHERE KEY1 = ? AND KEY2 = ?} [code=-1, state=23503] > at > > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219) > at > > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195) > at > > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59) > at > > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134) > at > > org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275) > at > > org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792) > at > > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268) > at > > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119) > > > Anything known changed? Is it a regression? > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*< > http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* >
