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 19:50:47 GMT
>  Ignoring our old constraints we are all green.

Not sure I follow.  Who or what is ignoring the old constraints?  And,
whatever process this is, you are green with the 2.3.0-SNAPSHOT?

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

Sorry, I'm not following this either, Romain.  Can you narrow down the EJB3
test to produce the issue?  I'm just now following what changed where and
what's not working with 2.3.0-SNAPSHOT.

Thanks, Kevin


On Thu, May 23, 2013 at 9:05 AM, Romain Manni-Bucau
<rmannibucau@gmail.com>wrote:

> 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