openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: differents constraints?
Date Thu, 23 May 2013 13:55:29 GMT
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
<rmannibucau@gmail.com>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*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message