You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openjpa.apache.org by Donald Woods <dw...@apache.org> on 2010/01/19 04:57:54 UTC

[DISCUSS] Time for an OpenJPA 2.0.0 release?

We're in pretty good shape for a 2.0.0 release.
Trunk is passing the JPA 2.0 TCK.
We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
and MS SQL as we have for any release.

Now, we could either release a Milestone 4 release and continue to work
on docs, samples, performance and the backlog issues or we could go
ahead and plan on cutting a 2.0.0 branch later this week with plans to
continue improving the 2.0 codebase in maintenance releases at least
every quarter.

If you have any critical issues that you feel need to be resolved before
we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
the Priority, along with replying to this discussion thread with the
details of the issues you would like considered.  After a couple days of
discussions, we'll revisit the open issues and decide on which route to
take.


Thanks,
Donald

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Donald Woods <dw...@apache.org>.

Forgot to copy the users list on this....

-Donald


On 1/18/10 10:57 PM, Donald Woods wrote:
> We're in pretty good shape for a 2.0.0 release.
> Trunk is passing the JPA 2.0 TCK.
> We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> and MS SQL as we have for any release.
> 
> Now, we could either release a Milestone 4 release and continue to work
> on docs, samples, performance and the backlog issues or we could go
> ahead and plan on cutting a 2.0.0 branch later this week with plans to
> continue improving the 2.0 codebase in maintenance releases at least
> every quarter.
> 
> If you have any critical issues that you feel need to be resolved before
> we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> the Priority, along with replying to this discussion thread with the
> details of the issues you would like considered.  After a couple days of
> discussions, we'll revisit the open issues and decide on which route to
> take.
> 
> 
> Thanks,
> Donald
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Michael Dick <mi...@gmail.com>.

On Thu, Jan 28, 2010 at 1:21 PM, Miłosz Tylenda <mt...@o2.pl> wrote:

> Hi Kevin,
>
> The failure depends on the order of tests being executed and this is
> probably why my previous test run did not fail at these two.
>
> Most likely there is nothing unique in PostgreSQL's date handling, maybe it
> is just more sensitive to differences between date/time column variants.
> Dates should be mapped to DATE and timestamps to ABSTIME, at least our
> dictionary specifies them such. What's unfortunate in our tests is that we
> have multiple entities which map to tables with same names but different
> columns, RuntimeTest1 in this case. Probably most of us have been struggling
> with that inconvenience already.
>
> RuntimeTest1 in two tests in question is defined as you described. This
> results in mapping to DATE column. Some other RuntimeTest1 omit the
> annotation which forces mapping to ABSTIME column. Maybe this should also
> map to DATE but I found nothing specific to PostgreSQL here. Anyway, our
> mapping mechanism is not perfect with such subtle changes to table
> definitions and hence errors.
>
> Maybe some of the test should drop/create their tables but the only
> reliable solution is that we don't create tables with same names but
> different columns. Unless we want to test the mapping tool :)
>

+1. Cleaning this up  (removing duplicate mappings) would be a good thing
and might speed up the test bucket a bit. I remember seeing a lot of time
consuming ALTER TABLE statements with DB2 (haven't looked recently though).

-mike



> Cheers,
> Milosz
>
>
> > Hi Milosz,
> > It seems that PostgreSQL is having problems with TemporalType.DATE
> fields.
> > The two tests below are failing because the RuntimeTest1 entity
> definition
> > can't be persisted to the database.  The field it's complaining about is
> > below...
> >
> >     @Temporal(TemporalType.DATE)
> >     private Date dateField;
> >
> > Any uniqueness with Date fields in PostgreSQL?
> >
> > Kevin
> >
> > On Sat, Jan 23, 2010 at 7:31 AM, Miłosz Tylenda <mt...@o2.pl> wrote:
> >
> > > Hi All.
> > >
> > > I re-ran the tests on PostgreSQL and the auto-increment failures
> vanished.
> > >
> > > What's new, it is something related to cache or date handling - I
> observed
> > > two new failures. Stack traces below.
> > >
> > > Regards,
> > > Milosz
> > >
> > >
> > >
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
> > >
> > >
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
> > >
> > >
> > > Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 57.511
> sec
> > > <<< FAILURE!
> > >
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
> > >  Time elapsed: 1.441 sec  <<< ERROR!
> > > <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with
> working
> > > copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a
> newer
> > > Subversion client fatal store error>
> > > org.apache.openjpa.persistence.RollbackExc
> > > eption: The transaction has been rolled back.  See the nested
> exceptions
> > > for details on the errors that occurred.
> > >        at
> > >
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
> > >        at
> > >
> org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
> > >        at
> > >
> org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >        at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >        at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at junit.framework.TestCase.runTest(TestCase.java:154)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
> > >        at junit.framework.TestCase.runBare(TestCase.java:127)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
> > >        at junit.framework.TestResult$1.protect(TestResult.java:106)
> > >        at junit.framework.TestResult.runProtected(TestResult.java:124)
> > >        at junit.framework.TestResult.run(TestResult.java:109)
> > >        at junit.framework.TestCase.run(TestCase.java:118)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
> > >        at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > >        at junit.framework.TestSuite.run(TestSuite.java:203)
> > >        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> > >         at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at
> > >
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> > >        at
> > >
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> > >        at
> > >
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> > >        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >        at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >        at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at
> > >
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> > >        at
> > >
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> > > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > > please get a newer Subversion client fatal general error>
> > > org.apache.openjpa.persistenc
> > > e.PersistenceException: The transaction has been rolled back.  See the
> > > nested exceptions for details on the errors that occurred.
> > >        at
> > >
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
> > >        at
> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
> > >        at
> > > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
> > >        at
> > >
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
> > >        at
> > >
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> > >        at
> org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
> > >        at
> > >
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
> > >        ... 31 more
> > > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > > please get a newer Subversion client nonfatal general error>
> > > org.apache.openjpa.persist
> > > ence.PersistenceException: ERROR: column "datefield" is of type abstime
> but
> > > expression is of type date
> > >  Hint: You will need to rewrite or cast the expression.
> > >  Position: 146 {prepstmnt 33138943 INSERT INTO RuntimeTest1 (id,
> > > bigDecimalField, bigIntegerField, booleanField, booleanObjField,
> byteField,
> > > byteObjfield, charField, charObjField, dateField, doubleField,
> > > doubleObjField, floatFiel
> > > d, floatObjField, intField, intObjField, localeField, longField,
> > > longObjField, shortField, shortObjField, stringField, transString,
> DTYPE,
> > > SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?,
> > > ?, ?, ?, ?, ?,
> > >  ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> > > (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null)
> null,
> > > (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int)
> 0,
> > > (null) nul
> > > l, (null) null, (long) 0, (null) null, (short) 0, (null) null, (null)
> null,
> > > (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> > > state=42804]
> > > FailedObject:
> > >
> org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@9da711
> > >        at
> > > org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> > >        at
> > >
> org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> > >        ... 38 more
> > >
> > >
> > > Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.9
> sec
> > > <<< FAILURE!
> > >
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
> > >  Time elapsed: 1.739 sec  <<< ERROR!
> > > <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with
> working
> > > copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a
> newer
> > > Subversion client fatal store error>
> > > org.apache.openjpa.persistence.RollbackExc
> > > eption: The transaction has been rolled back.  See the nested
> exceptions
> > > for details on the errors that occurred.
> > >        at
> > >
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
> > >        at
> > >
> org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
> > >        at
> > >
> org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >        at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >        at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at junit.framework.TestCase.runTest(TestCase.java:154)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
> > >        at junit.framework.TestCase.runBare(TestCase.java:127)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
> > >        at junit.framework.TestResult$1.protect(TestResult.java:106)
> > >        at junit.framework.TestResult.runProtected(TestResult.java:124)
> > >        at junit.framework.TestResult.run(TestResult.java:109)
> > >        at junit.framework.TestCase.run(TestCase.java:118)
> > >        at
> > >
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
> > >        at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > >        at junit.framework.TestSuite.run(TestSuite.java:203)
> > >        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> > >         at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at
> > >
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> > >        at
> > >
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> > >        at
> > >
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> > >        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >        at
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >        at
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >        at java.lang.reflect.Method.invoke(Method.java:597)
> > >         at
> > >
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> > >        at
> > >
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> > > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > > please get a newer Subversion client fatal general error>
> > > org.apache.openjpa.persistenc
> > > e.PersistenceException: The transaction has been rolled back.  See the
> > > nested exceptions for details on the errors that occurred.
> > >        at
> > >
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
> > >        at
> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
> > >        at
> > > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
> > >        at
> > >
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
> > >        at
> > >
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> > >        at
> org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
> > >        at
> > >
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
> > >        ... 31 more
> > > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > > please get a newer Subversion client nonfatal general error>
> > > org.apache.openjpa.persist
> > > ence.PersistenceException: ERROR: column "datefield" is of type abstime
> but
> > > expression is of type date
> > >  Hint: You will need to rewrite or cast the expression.
> > >  Position: 146 {prepstmnt 7445208 INSERT INTO RuntimeTest1 (id,
> > > bigDecimalField, bigIntegerField, booleanField, booleanObjField,
> byteField,
> > > byteObjfield, charField, charObjField, dateField, doubleField,
> > > doubleObjField, floatField
> > > , floatObjField, intField, intObjField, localeField, longField,
> > > longObjField, shortField, shortObjField, stringField, transString,
> DTYPE,
> > > SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?,
> > > ?, ?, ?, ?, ?,
> > > ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> > > (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null)
> null,
> > > (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int)
> 0,
> > > (null) null
> > > , (null) null, (long) 0, (null) null, (short) 0, (null) null, (null)
> null,
> > > (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> > > state=42804]
> > > FailedObject:
> > >
> org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@768bd0
> > >        at
> > > org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
> > >        at
> > >
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
> > >        at
> > >
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> > >        at
> > >
> org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
> > >        at
> > >
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> > >        ... 38 more
> > >
> > >
> > >
> > >
> > > > Milosz,
> > > >
> > > > Thanks again for running the jUnits on PostgreSQL.  It uncovered a
> nasty
> > > pest, particularly unfriendly to PostgreSQL.  The problem is fixed and
> the
> > > changes are in trunk.  rev. 902177.
> > > >
> > > > -Jeremy
> > > >
> > > >
> > > > On Tue, Jan 19, 2010 at 3:22 PM, Miłosz Tylenda <mt...@o2.pl>
> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Recently the test suite on PostgreSQL got a few new failures related
> to
> > > auto-increment columns, probably after introducing delimiter support. I
> have
> > > communicated the details to Jeremy.
> > > >
> > > > Also, OPENJPA-1289 seems to be resolved.
> > > >
> > > > Regards,
> > > > Milosz
> > > >
> > > >
> > > >
> > > > > I'd also like to see OPENJPA-1410 make it into the release.  This
> bug
> > > > > prevents OpenJPA 2.0 from running in some environments.  Donald and
> I
> > > have
> > > > > been looking into the problem and it is tagged as critical.
> > > > >
> > > > > -Jeremy
> > > > >
> > > > > On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <
> > > michael.d.dick@gmail.com>wrote:
> > > > >
> > > > > > There's also the issue of WriteBehind support (OPENJPA-1150).
> This
> > > work
> > > > > > never got to the point where I'd be really comfortable including
> it
> > > in
> > > > > > 2.0.0. 2.1.0 would be a better target though and I'm inclined to
> back
> > > out
> > > > > > the code for the upcoming release.
> > > > > >
> > > > > > -mike
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <
> kwsutter@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Donald,
> > > > > > > I'd like to get the default settings for the DataCache figured
> out
> > > before
> > > > > > > we
> > > > > > > cut a 2.0 release [1].  We've been running with this turned
> "on"
> > > for our
> > > > > > > performance benchmarks, so why not have this as our default?
>  I'm
> > > running
> > > > > > > our JUnit bucket as we speak...
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Kevin
> > > > > > >
> > > > > > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > > > > > >
> > > > > > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <
> dwoods@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > > We're in pretty good shape for a 2.0.0 release.
> > > > > > > > Trunk is passing the JPA 2.0 TCK.
> > > > > > > > We have the broadest/best junit results over Derby, DB2,
> Oracle,
> > > MySQL
> > > > > > > > and MS SQL as we have for any release.
> > > > > > > >
> > > > > > > > Now, we could either release a Milestone 4 release and
> continue
> > > to work
> > > > > > > > on docs, samples, performance and the backlog issues or we
> could
> > > go
> > > > > > > > ahead and plan on cutting a 2.0.0 branch later this week with
> > > plans to
> > > > > > > > continue improving the 2.0 codebase in maintenance releases
> at
> > > least
> > > > > > > > every quarter.
> > > > > > > >
> > > > > > > > If you have any critical issues that you feel need to be
> resolved
> > > > > > before
> > > > > > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0
> and
> > > set
> > > > > > > > the Priority, along with replying to this discussion thread
> with
> > > the
> > > > > > > > details of the issues you would like considered.  After a
> couple
> > > days
> > > > > > of
> > > > > > > > discussions, we'll revisit the open issues and decide on
> which
> > > route to
> > > > > > > > take.
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Donald
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Miłosz Tylenda <mt...@o2.pl>.

Hi Kevin,

The failure depends on the order of tests being executed and this is probably why my previous test run did not fail at these two.

Most likely there is nothing unique in PostgreSQL's date handling, maybe it is just more sensitive to differences between date/time column variants. Dates should be mapped to DATE and timestamps to ABSTIME, at least our dictionary specifies them such. What's unfortunate in our tests is that we have multiple entities which map to tables with same names but different columns, RuntimeTest1 in this case. Probably most of us have been struggling with that inconvenience already.

RuntimeTest1 in two tests in question is defined as you described. This results in mapping to DATE column. Some other RuntimeTest1 omit the annotation which forces mapping to ABSTIME column. Maybe this should also map to DATE but I found nothing specific to PostgreSQL here. Anyway, our mapping mechanism is not perfect with such subtle changes to table definitions and hence errors.

Maybe some of the test should drop/create their tables but the only reliable solution is that we don't create tables with same names but different columns. Unless we want to test the mapping tool :)

Cheers,
Milosz


> Hi Milosz,
> It seems that PostgreSQL is having problems with TemporalType.DATE fields.
> The two tests below are failing because the RuntimeTest1 entity definition
> can't be persisted to the database.  The field it's complaining about is
> below...
> 
>     @Temporal(TemporalType.DATE)
>     private Date dateField;
> 
> Any uniqueness with Date fields in PostgreSQL?
> 
> Kevin
> 
> On Sat, Jan 23, 2010 at 7:31 AM, Miłosz Tylenda <mt...@o2.pl> wrote:
> 
> > Hi All.
> >
> > I re-ran the tests on PostgreSQL and the auto-increment failures vanished.
> >
> > What's new, it is something related to cache or date handling - I observed
> > two new failures. Stack traces below.
> >
> > Regards,
> > Milosz
> >
> >
> > testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
> >
> > testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
> >
> >
> > Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 57.511 sec
> > <<< FAILURE!
> > testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
> >  Time elapsed: 1.441 sec  <<< ERROR!
> > <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working
> > copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer
> > Subversion client fatal store error>
> > org.apache.openjpa.persistence.RollbackExc
> > eption: The transaction has been rolled back.  See the nested exceptions
> > for details on the errors that occurred.
> >        at
> > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
> >        at
> > org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
> >        at
> > org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >        at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >        at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at junit.framework.TestCase.runTest(TestCase.java:154)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
> >        at junit.framework.TestCase.runBare(TestCase.java:127)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
> >        at junit.framework.TestResult$1.protect(TestResult.java:106)
> >        at junit.framework.TestResult.runProtected(TestResult.java:124)
> >        at junit.framework.TestResult.run(TestResult.java:109)
> >        at junit.framework.TestCase.run(TestCase.java:118)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
> >        at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >        at junit.framework.TestSuite.run(TestSuite.java:203)
> >        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> >         at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at
> > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> >        at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> >        at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> >        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >        at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >        at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at
> > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> >        at
> > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > please get a newer Subversion client fatal general error>
> > org.apache.openjpa.persistenc
> > e.PersistenceException: The transaction has been rolled back.  See the
> > nested exceptions for details on the errors that occurred.
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
> >        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
> >        at
> > org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> >        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
> >        at
> > org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
> >        at
> > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
> >        ... 31 more
> > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > please get a newer Subversion client nonfatal general error>
> > org.apache.openjpa.persist
> > ence.PersistenceException: ERROR: column "datefield" is of type abstime but
> > expression is of type date
> >  Hint: You will need to rewrite or cast the expression.
> >  Position: 146 {prepstmnt 33138943 INSERT INTO RuntimeTest1 (id,
> > bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField,
> > byteObjfield, charField, charObjField, dateField, doubleField,
> > doubleObjField, floatFiel
> > d, floatObjField, intField, intObjField, localeField, longField,
> > longObjField, shortField, shortObjField, stringField, transString, DTYPE,
> > SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > ?, ?, ?, ?, ?,
> >  ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> > (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null,
> > (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0,
> > (null) nul
> > l, (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null,
> > (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> > state=42804]
> > FailedObject:
> > org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@9da711
> >        at
> > org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
> >        at
> > org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
> >        at
> > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
> >        at
> > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
> >        at
> > org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
> >        at
> > org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
> >        at
> > org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
> >        at
> > org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> >        at
> > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
> >        at
> > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
> >        at
> > org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
> >        at
> > org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> >        at
> > org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
> >        at
> > org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> >        ... 38 more
> >
> >
> > Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.9 sec
> > <<< FAILURE!
> > testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
> >  Time elapsed: 1.739 sec  <<< ERROR!
> > <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working
> > copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer
> > Subversion client fatal store error>
> > org.apache.openjpa.persistence.RollbackExc
> > eption: The transaction has been rolled back.  See the nested exceptions
> > for details on the errors that occurred.
> >        at
> > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
> >        at
> > org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
> >        at
> > org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >        at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >        at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at junit.framework.TestCase.runTest(TestCase.java:154)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
> >        at junit.framework.TestCase.runBare(TestCase.java:127)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
> >        at junit.framework.TestResult$1.protect(TestResult.java:106)
> >        at junit.framework.TestResult.runProtected(TestResult.java:124)
> >        at junit.framework.TestResult.run(TestResult.java:109)
> >        at junit.framework.TestCase.run(TestCase.java:118)
> >        at
> > org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
> >        at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >        at junit.framework.TestSuite.run(TestSuite.java:203)
> >        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
> >         at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at
> > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> >        at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> >        at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> >        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >        at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >        at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >        at java.lang.reflect.Method.invoke(Method.java:597)
> >         at
> > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> >        at
> > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > please get a newer Subversion client fatal general error>
> > org.apache.openjpa.persistenc
> > e.PersistenceException: The transaction has been rolled back.  See the
> > nested exceptions for details on the errors that occurred.
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
> >        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
> >        at
> > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
> >        at
> > org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
> >        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
> >        at
> > org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
> >        at
> > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
> >        ... 31 more
> > Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> > with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> > please get a newer Subversion client nonfatal general error>
> > org.apache.openjpa.persist
> > ence.PersistenceException: ERROR: column "datefield" is of type abstime but
> > expression is of type date
> >  Hint: You will need to rewrite or cast the expression.
> >  Position: 146 {prepstmnt 7445208 INSERT INTO RuntimeTest1 (id,
> > bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField,
> > byteObjfield, charField, charObjField, dateField, doubleField,
> > doubleObjField, floatField
> > , floatObjField, intField, intObjField, localeField, longField,
> > longObjField, shortField, shortObjField, stringField, transString, DTYPE,
> > SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > ?, ?, ?, ?, ?,
> > ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> > (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null,
> > (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0,
> > (null) null
> > , (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null,
> > (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> > state=42804]
> > FailedObject:
> > org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@768bd0
> >        at
> > org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
> >        at
> > org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
> >        at
> > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
> >        at
> > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
> >        at
> > org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
> >        at
> > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
> >        at
> > org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
> >        at
> > org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
> >        at
> > org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> >        at
> > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
> >        at
> > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
> >        at
> > org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
> >        at
> > org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> >        at
> > org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
> >        at
> > org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> >        ... 38 more
> >
> >
> >
> >
> > > Milosz,
> > >
> > > Thanks again for running the jUnits on PostgreSQL.  It uncovered a nasty
> > pest, particularly unfriendly to PostgreSQL.  The problem is fixed and the
> > changes are in trunk.  rev. 902177.
> > >
> > > -Jeremy
> > >
> > >
> > > On Tue, Jan 19, 2010 at 3:22 PM, Miłosz Tylenda <mt...@o2.pl> wrote:
> > >
> > > Hi All,
> > >
> > > Recently the test suite on PostgreSQL got a few new failures related to
> > auto-increment columns, probably after introducing delimiter support. I have
> > communicated the details to Jeremy.
> > >
> > > Also, OPENJPA-1289 seems to be resolved.
> > >
> > > Regards,
> > > Milosz
> > >
> > >
> > >
> > > > I'd also like to see OPENJPA-1410 make it into the release.  This bug
> > > > prevents OpenJPA 2.0 from running in some environments.  Donald and I
> > have
> > > > been looking into the problem and it is tagged as critical.
> > > >
> > > > -Jeremy
> > > >
> > > > On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <
> > michael.d.dick@gmail.com>wrote:
> > > >
> > > > > There's also the issue of WriteBehind support (OPENJPA-1150). This
> > work
> > > > > never got to the point where I'd be really comfortable including it
> > in
> > > > > 2.0.0. 2.1.0 would be a better target though and I'm inclined to back
> > out
> > > > > the code for the upcoming release.
> > > > >
> > > > > -mike
> > > > >
> > > > >
> > > > > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi Donald,
> > > > > > I'd like to get the default settings for the DataCache figured out
> > before
> > > > > > we
> > > > > > cut a 2.0 release [1].  We've been running with this turned "on"
> > for our
> > > > > > performance benchmarks, so why not have this as our default?  I'm
> > running
> > > > > > our JUnit bucket as we speak...
> > > > > >
> > > > > > Thanks,
> > > > > > Kevin
> > > > > >
> > > > > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > > > > >
> > > > > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org>
> > wrote:
> > > > > >
> > > > > > > We're in pretty good shape for a 2.0.0 release.
> > > > > > > Trunk is passing the JPA 2.0 TCK.
> > > > > > > We have the broadest/best junit results over Derby, DB2, Oracle,
> > MySQL
> > > > > > > and MS SQL as we have for any release.
> > > > > > >
> > > > > > > Now, we could either release a Milestone 4 release and continue
> > to work
> > > > > > > on docs, samples, performance and the backlog issues or we could
> > go
> > > > > > > ahead and plan on cutting a 2.0.0 branch later this week with
> > plans to
> > > > > > > continue improving the 2.0 codebase in maintenance releases at
> > least
> > > > > > > every quarter.
> > > > > > >
> > > > > > > If you have any critical issues that you feel need to be resolved
> > > > > before
> > > > > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and
> > set
> > > > > > > the Priority, along with replying to this discussion thread with
> > the
> > > > > > > details of the issues you would like considered.  After a couple
> > days
> > > > > of
> > > > > > > discussions, we'll revisit the open issues and decide on which
> > route to
> > > > > > > take.
> > > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Donald
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Kevin Sutter <kw...@gmail.com>.

Hi Milosz,
It seems that PostgreSQL is having problems with TemporalType.DATE fields.
The two tests below are failing because the RuntimeTest1 entity definition
can't be persisted to the database.  The field it's complaining about is
below...

    @Temporal(TemporalType.DATE)
    private Date dateField;

Any uniqueness with Date fields in PostgreSQL?

Kevin

On Sat, Jan 23, 2010 at 7:31 AM, Miłosz Tylenda <mt...@o2.pl> wrote:

> Hi All.
>
> I re-ran the tests on PostgreSQL and the auto-increment failures vanished.
>
> What's new, it is something related to cache or date handling - I observed
> two new failures. Stack traces below.
>
> Regards,
> Milosz
>
>
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
>
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
>
>
> Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 57.511 sec
> <<< FAILURE!
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
>  Time elapsed: 1.441 sec  <<< ERROR!
> <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working
> copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer
> Subversion client fatal store error>
> org.apache.openjpa.persistence.RollbackExc
> eption: The transaction has been rolled back.  See the nested exceptions
> for details on the errors that occurred.
>        at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
>        at
> org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
>        at
> org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at junit.framework.TestCase.runTest(TestCase.java:154)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
>        at junit.framework.TestCase.runBare(TestCase.java:127)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
>        at junit.framework.TestResult$1.protect(TestResult.java:106)
>        at junit.framework.TestResult.runProtected(TestResult.java:124)
>        at junit.framework.TestResult.run(TestResult.java:109)
>        at junit.framework.TestCase.run(TestCase.java:118)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
>        at junit.framework.TestSuite.runTest(TestSuite.java:208)
>        at junit.framework.TestSuite.run(TestSuite.java:203)
>        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>        at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>        at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>        at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> please get a newer Subversion client fatal general error>
> org.apache.openjpa.persistenc
> e.PersistenceException: The transaction has been rolled back.  See the
> nested exceptions for details on the errors that occurred.
>        at
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
>        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
>        at
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
>        at
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
>        at
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
>        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
>        at
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
>        at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
>        ... 31 more
> Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> please get a newer Subversion client nonfatal general error>
> org.apache.openjpa.persist
> ence.PersistenceException: ERROR: column "datefield" is of type abstime but
> expression is of type date
>  Hint: You will need to rewrite or cast the expression.
>  Position: 146 {prepstmnt 33138943 INSERT INTO RuntimeTest1 (id,
> bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField,
> byteObjfield, charField, charObjField, dateField, doubleField,
> doubleObjField, floatFiel
> d, floatObjField, intField, intObjField, localeField, longField,
> longObjField, shortField, shortObjField, stringField, transString, DTYPE,
> SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?,
>  ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null,
> (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0,
> (null) nul
> l, (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null,
> (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> state=42804]
> FailedObject:
> org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@9da711
>        at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
>        at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
>        at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
>        at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
>        at
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
>        at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
>        at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
>        at
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
>        at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
>        at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
>        at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
>        at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
>        at
> org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
>        at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
>        ... 38 more
>
>
> Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.9 sec
> <<< FAILURE!
> testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)
>  Time elapsed: 1.739 sec  <<< ERROR!
> <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working
> copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer
> Subversion client fatal store error>
> org.apache.openjpa.persistence.RollbackExc
> eption: The transaction has been rolled back.  See the nested exceptions
> for details on the errors that occurred.
>        at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
>        at
> org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
>        at
> org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at junit.framework.TestCase.runTest(TestCase.java:154)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
>        at junit.framework.TestCase.runBare(TestCase.java:127)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
>        at junit.framework.TestResult$1.protect(TestResult.java:106)
>        at junit.framework.TestResult.runProtected(TestResult.java:124)
>        at junit.framework.TestResult.run(TestResult.java:109)
>        at junit.framework.TestCase.run(TestCase.java:118)
>        at
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
>        at junit.framework.TestSuite.runTest(TestSuite.java:208)
>        at junit.framework.TestSuite.run(TestSuite.java:203)
>        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>        at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>        at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
>        at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> please get a newer Subversion client fatal general error>
> org.apache.openjpa.persistenc
> e.PersistenceException: The transaction has been rolled back.  See the
> nested exceptions for details on the errors that occurred.
>        at
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
>        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
>        at
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
>        at
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
>        at
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
>        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
>        at
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
>        at
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
>        ... 31 more
> Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work
> with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..';
> please get a newer Subversion client nonfatal general error>
> org.apache.openjpa.persist
> ence.PersistenceException: ERROR: column "datefield" is of type abstime but
> expression is of type date
>  Hint: You will need to rewrite or cast the expression.
>  Position: 146 {prepstmnt 7445208 INSERT INTO RuntimeTest1 (id,
> bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField,
> byteObjfield, charField, charObjField, dateField, doubleField,
> doubleObjField, floatField
> , floatObjField, intField, intObjField, localeField, longField,
> longObjField, shortField, shortObjField, stringField, transString, DTYPE,
> SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null,
> (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null,
> (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0,
> (null) null
> , (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null,
> (null) null, (String) dataRt1, (null) null, (null) null]} [code=0,
> state=42804]
> FailedObject:
> org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@768bd0
>        at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
>        at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
>        at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
>        at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
>        at
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
>        at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
>        at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
>        at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
>        at
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
>        at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
>        at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
>        at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
>        at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
>        at
> org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
>        at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
>        ... 38 more
>
>
>
>
> > Milosz,
> >
> > Thanks again for running the jUnits on PostgreSQL.  It uncovered a nasty
> pest, particularly unfriendly to PostgreSQL.  The problem is fixed and the
> changes are in trunk.  rev. 902177.
> >
> > -Jeremy
> >
> >
> > On Tue, Jan 19, 2010 at 3:22 PM, Miłosz Tylenda <mt...@o2.pl> wrote:
> >
> > Hi All,
> >
> > Recently the test suite on PostgreSQL got a few new failures related to
> auto-increment columns, probably after introducing delimiter support. I have
> communicated the details to Jeremy.
> >
> > Also, OPENJPA-1289 seems to be resolved.
> >
> > Regards,
> > Milosz
> >
> >
> >
> > > I'd also like to see OPENJPA-1410 make it into the release.  This bug
> > > prevents OpenJPA 2.0 from running in some environments.  Donald and I
> have
> > > been looking into the problem and it is tagged as critical.
> > >
> > > -Jeremy
> > >
> > > On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <
> michael.d.dick@gmail.com>wrote:
> > >
> > > > There's also the issue of WriteBehind support (OPENJPA-1150). This
> work
> > > > never got to the point where I'd be really comfortable including it
> in
> > > > 2.0.0. 2.1.0 would be a better target though and I'm inclined to back
> out
> > > > the code for the upcoming release.
> > > >
> > > > -mike
> > > >
> > > >
> > > > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com>
> wrote:
> > > >
> > > > > Hi Donald,
> > > > > I'd like to get the default settings for the DataCache figured out
> before
> > > > > we
> > > > > cut a 2.0 release [1].  We've been running with this turned "on"
> for our
> > > > > performance benchmarks, so why not have this as our default?  I'm
> running
> > > > > our JUnit bucket as we speak...
> > > > >
> > > > > Thanks,
> > > > > Kevin
> > > > >
> > > > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > > > >
> > > > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org>
> wrote:
> > > > >
> > > > > > We're in pretty good shape for a 2.0.0 release.
> > > > > > Trunk is passing the JPA 2.0 TCK.
> > > > > > We have the broadest/best junit results over Derby, DB2, Oracle,
> MySQL
> > > > > > and MS SQL as we have for any release.
> > > > > >
> > > > > > Now, we could either release a Milestone 4 release and continue
> to work
> > > > > > on docs, samples, performance and the backlog issues or we could
> go
> > > > > > ahead and plan on cutting a 2.0.0 branch later this week with
> plans to
> > > > > > continue improving the 2.0 codebase in maintenance releases at
> least
> > > > > > every quarter.
> > > > > >
> > > > > > If you have any critical issues that you feel need to be resolved
> > > > before
> > > > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and
> set
> > > > > > the Priority, along with replying to this discussion thread with
> the
> > > > > > details of the issues you would like considered.  After a couple
> days
> > > > of
> > > > > > discussions, we'll revisit the open issues and decide on which
> route to
> > > > > > take.
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Donald
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
>
>
>
>
>
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Miłosz Tylenda <mt...@o2.pl>.

Hi All.

I re-ran the tests on PostgreSQL and the auto-increment failures vanished.

What's new, it is something related to cache or date handling - I observed two new failures. Stack traces below.

Regards,
Milosz

testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)
testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)


Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 57.511 sec <<< FAILURE!
testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestSJVMCache)  Time elapsed: 1.441 sec  <<< ERROR!
<openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client fatal store error> org.apache.openjpa.persistence.RollbackExc
eption: The transaction has been rolled back.  See the nested exceptions for details on the errors that occurred.
        at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
        at org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
        at org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client fatal general error> org.apache.openjpa.persistenc
e.PersistenceException: The transaction has been rolled back.  See the nested exceptions for details on the errors that occurred.
        at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
        at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
        at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
        at org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
        at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
        at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
        ... 31 more
Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client nonfatal general error> org.apache.openjpa.persist
ence.PersistenceException: ERROR: column "datefield" is of type abstime but expression is of type date
  Hint: You will need to rewrite or cast the expression.
  Position: 146 {prepstmnt 33138943 INSERT INTO RuntimeTest1 (id, bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField, byteObjfield, charField, charObjField, dateField, doubleField, doubleObjField, floatFiel
d, floatObjField, intField, intObjField, localeField, longField, longObjField, shortField, shortObjField, stringField, transString, DTYPE, SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
 ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null, (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null, (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0, (null) nul
l, (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null, (null) null, (String) dataRt1, (null) null, (null) null]} [code=0, state=42804]
FailedObject: org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@9da711
        at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
        at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
        at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
        at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
        at org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
        at org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
        at org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
        at org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
        at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
        at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
        at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
        at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
        at org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
        at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
        ... 38 more


Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.9 sec <<< FAILURE!
testQueryImplicitEvictions(org.apache.openjpa.persistence.datacache.TestDataCachePCDataGenerator)  Time elapsed: 1.739 sec  <<< ERROR!
<openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client fatal store error> org.apache.openjpa.persistence.RollbackExc
eption: The transaction has been rolled back.  See the nested exceptions for details on the errors that occurred.
        at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:568)
        at org.apache.openjpa.persistence.common.utils.AbstractTestCase.endTx(AbstractTestCase.java:278)
        at org.apache.openjpa.persistence.datacache.CacheTest.testQueryImplicitEvictions(CacheTest.java:1135)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:514)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:501)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:477)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:177)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client fatal general error> org.apache.openjpa.persistenc
e.PersistenceException: The transaction has been rolled back.  See the nested exceptions for details on the errors that occurred.
        at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2273)
        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2115)
        at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2013)
        at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1931)
        at org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1455)
        at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:903)
        at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:551)
        ... 31 more
Caused by: <openjpa-2.0.0-SNAPSHOT-rsvn: This client is too old to work with working copy '/alt/eclipse322/workspace/open-jpa/openjpa-lib/..'; please get a newer Subversion client nonfatal general error> org.apache.openjpa.persist
ence.PersistenceException: ERROR: column "datefield" is of type abstime but expression is of type date
  Hint: You will need to rewrite or cast the expression.
  Position: 146 {prepstmnt 7445208 INSERT INTO RuntimeTest1 (id, bigDecimalField, bigIntegerField, booleanField, booleanObjField, byteField, byteObjfield, charField, charObjField, dateField, doubleField, doubleObjField, floatField
, floatObjField, intField, intObjField, localeField, longField, longObjField, shortField, shortObjField, stringField, transString, DTYPE, SELFONEONE_ID, TRANSFIELD_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 51, (null) null, (null) null, (boolean) false, (null) null, (byte) 0, (null) null, (int) 0, (null) null, (null) null, (double) 0.0, (null) null, (float) 0.0, (null) null, (int) 0, (null) null
, (null) null, (long) 0, (null) null, (short) 0, (null) null, (null) null, (null) null, (String) dataRt1, (null) null, (null) null]} [code=0, state=42804]
FailedObject: org.apache.openjpa.persistence.datacache.common.apps.RuntimeTest1@768bd0
        at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4831)
        at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4784)
        at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:137)
        at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:78)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:143)
        at org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:80)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
        at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
        at org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
        at org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
        at org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
        at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
        at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
        at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:680)
        at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
        at org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:540)
        at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
        ... 38 more




> Milosz,
> 
> Thanks again for running the jUnits on PostgreSQL.  It uncovered a nasty pest, particularly unfriendly to PostgreSQL.  The problem is fixed and the changes are in trunk.  rev. 902177.
> 
> -Jeremy
> 
> 
> On Tue, Jan 19, 2010 at 3:22 PM, Miłosz Tylenda <mt...@o2.pl> wrote:
> 
> Hi All,
> 
> Recently the test suite on PostgreSQL got a few new failures related to auto-increment columns, probably after introducing delimiter support. I have communicated the details to Jeremy.
> 
> Also, OPENJPA-1289 seems to be resolved.
> 
> Regards,
> Milosz
> 
> 
> 
> > I'd also like to see OPENJPA-1410 make it into the release.  This bug
> > prevents OpenJPA 2.0 from running in some environments.  Donald and I have
> > been looking into the problem and it is tagged as critical.
> >
> > -Jeremy
> >
> > On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <mi...@gmail.com>wrote:
> >
> > > There's also the issue of WriteBehind support (OPENJPA-1150). This work
> > > never got to the point where I'd be really comfortable including it in
> > > 2.0.0. 2.1.0 would be a better target though and I'm inclined to back out
> > > the code for the upcoming release.
> > >
> > > -mike
> > >
> > >
> > > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com> wrote:
> > >
> > > > Hi Donald,
> > > > I'd like to get the default settings for the DataCache figured out before
> > > > we
> > > > cut a 2.0 release [1].  We've been running with this turned "on" for our
> > > > performance benchmarks, so why not have this as our default?  I'm running
> > > > our JUnit bucket as we speak...
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > > >
> > > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org> wrote:
> > > >
> > > > > We're in pretty good shape for a 2.0.0 release.
> > > > > Trunk is passing the JPA 2.0 TCK.
> > > > > We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> > > > > and MS SQL as we have for any release.
> > > > >
> > > > > Now, we could either release a Milestone 4 release and continue to work
> > > > > on docs, samples, performance and the backlog issues or we could go
> > > > > ahead and plan on cutting a 2.0.0 branch later this week with plans to
> > > > > continue improving the 2.0 codebase in maintenance releases at least
> > > > > every quarter.
> > > > >
> > > > > If you have any critical issues that you feel need to be resolved
> > > before
> > > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> > > > > the Priority, along with replying to this discussion thread with the
> > > > > details of the issues you would like considered.  After a couple days
> > > of
> > > > > discussions, we'll revisit the open issues and decide on which route to
> > > > > take.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Donald
> > > > >
> > > >
> > >
> >
> 
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Jeremy Bauer <te...@gmail.com>.

Milosz,

Thanks again for running the jUnits on PostgreSQL.  It uncovered a nasty
pest, particularly unfriendly to PostgreSQL.  The problem is fixed and the
changes are in trunk.  rev. 902177.

-Jeremy

On Tue, Jan 19, 2010 at 3:22 PM, Miłosz Tylenda <mt...@o2.pl> wrote:

> Hi All,
>
> Recently the test suite on PostgreSQL got a few new failures related to
> auto-increment columns, probably after introducing delimiter support. I have
> communicated the details to Jeremy.
>
> Also, OPENJPA-1289 seems to be resolved.
>
> Regards,
> Milosz
>
> > I'd also like to see OPENJPA-1410 make it into the release.  This bug
> > prevents OpenJPA 2.0 from running in some environments.  Donald and I
> have
> > been looking into the problem and it is tagged as critical.
> >
> > -Jeremy
> >
> > On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <michael.d.dick@gmail.com
> >wrote:
> >
> > > There's also the issue of WriteBehind support (OPENJPA-1150). This work
> > > never got to the point where I'd be really comfortable including it in
> > > 2.0.0. 2.1.0 would be a better target though and I'm inclined to back
> out
> > > the code for the upcoming release.
> > >
> > > -mike
> > >
> > >
> > > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com>
> wrote:
> > >
> > > > Hi Donald,
> > > > I'd like to get the default settings for the DataCache figured out
> before
> > > > we
> > > > cut a 2.0 release [1].  We've been running with this turned "on" for
> our
> > > > performance benchmarks, so why not have this as our default?  I'm
> running
> > > > our JUnit bucket as we speak...
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > > >
> > > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org>
> wrote:
> > > >
> > > > > We're in pretty good shape for a 2.0.0 release.
> > > > > Trunk is passing the JPA 2.0 TCK.
> > > > > We have the broadest/best junit results over Derby, DB2, Oracle,
> MySQL
> > > > > and MS SQL as we have for any release.
> > > > >
> > > > > Now, we could either release a Milestone 4 release and continue to
> work
> > > > > on docs, samples, performance and the backlog issues or we could go
> > > > > ahead and plan on cutting a 2.0.0 branch later this week with plans
> to
> > > > > continue improving the 2.0 codebase in maintenance releases at
> least
> > > > > every quarter.
> > > > >
> > > > > If you have any critical issues that you feel need to be resolved
> > > before
> > > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and
> set
> > > > > the Priority, along with replying to this discussion thread with
> the
> > > > > details of the issues you would like considered.  After a couple
> days
> > > of
> > > > > discussions, we'll revisit the open issues and decide on which
> route to
> > > > > take.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Donald
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Miłosz Tylenda <mt...@o2.pl>.

Hi All,

Recently the test suite on PostgreSQL got a few new failures related to auto-increment columns, probably after introducing delimiter support. I have communicated the details to Jeremy.

Also, OPENJPA-1289 seems to be resolved.

Regards,
Milosz

> I'd also like to see OPENJPA-1410 make it into the release.  This bug
> prevents OpenJPA 2.0 from running in some environments.  Donald and I have
> been looking into the problem and it is tagged as critical.
> 
> -Jeremy
> 
> On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <mi...@gmail.com>wrote:
> 
> > There's also the issue of WriteBehind support (OPENJPA-1150). This work
> > never got to the point where I'd be really comfortable including it in
> > 2.0.0. 2.1.0 would be a better target though and I'm inclined to back out
> > the code for the upcoming release.
> >
> > -mike
> >
> >
> > On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com> wrote:
> >
> > > Hi Donald,
> > > I'd like to get the default settings for the DataCache figured out before
> > > we
> > > cut a 2.0 release [1].  We've been running with this turned "on" for our
> > > performance benchmarks, so why not have this as our default?  I'm running
> > > our JUnit bucket as we speak...
> > >
> > > Thanks,
> > > Kevin
> > >
> > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> > >
> > > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org> wrote:
> > >
> > > > We're in pretty good shape for a 2.0.0 release.
> > > > Trunk is passing the JPA 2.0 TCK.
> > > > We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> > > > and MS SQL as we have for any release.
> > > >
> > > > Now, we could either release a Milestone 4 release and continue to work
> > > > on docs, samples, performance and the backlog issues or we could go
> > > > ahead and plan on cutting a 2.0.0 branch later this week with plans to
> > > > continue improving the 2.0 codebase in maintenance releases at least
> > > > every quarter.
> > > >
> > > > If you have any critical issues that you feel need to be resolved
> > before
> > > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> > > > the Priority, along with replying to this discussion thread with the
> > > > details of the issues you would like considered.  After a couple days
> > of
> > > > discussions, we'll revisit the open issues and decide on which route to
> > > > take.
> > > >
> > > >
> > > > Thanks,
> > > > Donald
> > > >
> > >
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Jeremy Bauer <te...@gmail.com>.

I'd also like to see OPENJPA-1410 make it into the release.  This bug
prevents OpenJPA 2.0 from running in some environments.  Donald and I have
been looking into the problem and it is tagged as critical.

-Jeremy

On Tue, Jan 19, 2010 at 11:44 AM, Michael Dick <mi...@gmail.com>wrote:

> There's also the issue of WriteBehind support (OPENJPA-1150). This work
> never got to the point where I'd be really comfortable including it in
> 2.0.0. 2.1.0 would be a better target though and I'm inclined to back out
> the code for the upcoming release.
>
> -mike
>
>
> On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com> wrote:
>
> > Hi Donald,
> > I'd like to get the default settings for the DataCache figured out before
> > we
> > cut a 2.0 release [1].  We've been running with this turned "on" for our
> > performance benchmarks, so why not have this as our default?  I'm running
> > our JUnit bucket as we speak...
> >
> > Thanks,
> > Kevin
> >
> > [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
> >
> > On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org> wrote:
> >
> > > We're in pretty good shape for a 2.0.0 release.
> > > Trunk is passing the JPA 2.0 TCK.
> > > We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> > > and MS SQL as we have for any release.
> > >
> > > Now, we could either release a Milestone 4 release and continue to work
> > > on docs, samples, performance and the backlog issues or we could go
> > > ahead and plan on cutting a 2.0.0 branch later this week with plans to
> > > continue improving the 2.0 codebase in maintenance releases at least
> > > every quarter.
> > >
> > > If you have any critical issues that you feel need to be resolved
> before
> > > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> > > the Priority, along with replying to this discussion thread with the
> > > details of the issues you would like considered.  After a couple days
> of
> > > discussions, we'll revisit the open issues and decide on which route to
> > > take.
> > >
> > >
> > > Thanks,
> > > Donald
> > >
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Michael Dick <mi...@gmail.com>.

There's also the issue of WriteBehind support (OPENJPA-1150). This work
never got to the point where I'd be really comfortable including it in
2.0.0. 2.1.0 would be a better target though and I'm inclined to back out
the code for the upcoming release.

-mike


On Tue, Jan 19, 2010 at 11:15 AM, Kevin Sutter <kw...@gmail.com> wrote:

> Hi Donald,
> I'd like to get the default settings for the DataCache figured out before
> we
> cut a 2.0 release [1].  We've been running with this turned "on" for our
> performance benchmarks, so why not have this as our default?  I'm running
> our JUnit bucket as we speak...
>
> Thanks,
> Kevin
>
> [1]  https://issues.apache.org/jira/browse/OPENJPA-1469
>
> On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org> wrote:
>
> > We're in pretty good shape for a 2.0.0 release.
> > Trunk is passing the JPA 2.0 TCK.
> > We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> > and MS SQL as we have for any release.
> >
> > Now, we could either release a Milestone 4 release and continue to work
> > on docs, samples, performance and the backlog issues or we could go
> > ahead and plan on cutting a 2.0.0 branch later this week with plans to
> > continue improving the 2.0 codebase in maintenance releases at least
> > every quarter.
> >
> > If you have any critical issues that you feel need to be resolved before
> > we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> > the Priority, along with replying to this discussion thread with the
> > details of the issues you would like considered.  After a couple days of
> > discussions, we'll revisit the open issues and decide on which route to
> > take.
> >
> >
> > Thanks,
> > Donald
> >
>

Re: [DISCUSS] Time for an OpenJPA 2.0.0 release?

Posted by Kevin Sutter <kw...@gmail.com>.

Hi Donald,
I'd like to get the default settings for the DataCache figured out before we
cut a 2.0 release [1].  We've been running with this turned "on" for our
performance benchmarks, so why not have this as our default?  I'm running
our JUnit bucket as we speak...

Thanks,
Kevin

[1]  https://issues.apache.org/jira/browse/OPENJPA-1469

On Mon, Jan 18, 2010 at 9:57 PM, Donald Woods <dw...@apache.org> wrote:

> We're in pretty good shape for a 2.0.0 release.
> Trunk is passing the JPA 2.0 TCK.
> We have the broadest/best junit results over Derby, DB2, Oracle, MySQL
> and MS SQL as we have for any release.
>
> Now, we could either release a Milestone 4 release and continue to work
> on docs, samples, performance and the backlog issues or we could go
> ahead and plan on cutting a 2.0.0 branch later this week with plans to
> continue improving the 2.0 codebase in maintenance releases at least
> every quarter.
>
> If you have any critical issues that you feel need to be resolved before
> we release 2.0.0, please update the JIRA Fix Version to 2.0.0 and set
> the Priority, along with replying to this discussion thread with the
> details of the issues you would like considered.  After a couple days of
> discussions, we'll revisit the open issues and decide on which route to
> take.
>
>
> Thanks,
> Donald
>