openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: differents constraints?
Date Thu, 23 May 2013 14:05:11 GMT
that's an ejb 3 test playing with derived id. We kept the database used
with openjpa 2.2.0 upgrading the library to 2.3.0-SNAPSHOT and saw the
failure at this moment.

Ignoring our old constraints we are all green.

The diff between both generation are constraints which are not exactly the
same (one got a derby "reference" in the constraint where the other
generation ignored it)

*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*



2013/5/23 Kevin Sutter <kwsutter@gmail.com>

> 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