Nabble - OpenJPA Developers

Re: JIRA references in documentation?

2009-11-24T10:12:58Z

Well, the JIRA pointers were my idea...

The thought being, that if someone is concerned with a particular
migration issue, then they obviously are working with their application
source code and should have no problems looking at our SVN commits to
see the exact junits that demonstrate the behavioral differences between
1.x and 2.0.

The descriptions could probably use some more text, like documenting
that a method returns IllegalArgumentException now instead of a
XYZException, which would remove the need for the JIRA links, but we
should then create a Migration section in the release notes which point
to these JIRAs, like the Derby team does for their releases (which they
call Issues due to them being migration issues) -

http://db.apache.org/derby/releases/release-10.5.3.0.cgi#Issues

-Donald

Kevin Sutter wrote:

> Hi,
> While I was looking for some information in our documentation in trunk, I
> came across several references to JIRAs. The section on Incompatibilities
> [1] really stuck out for me. I'm not thrilled with this approach. For a
> few reasons...
>
> o It forces customers to go find some other tool (JIRA) to look up
> additional information. We've found several Users and even some Dev mailing
> list contributors that don't know anything about JIRA.
>
> o It makes us look "lazy". Instead of completing the documentation, we're
> telling customers to go on a scavenger hunt.
>
> o Some of the references are basically worthless. For example, in the
> section on detach [2], there is a reference to OPENJPA-1215 for more
> testcases that document the situation. But, there are no patches or commits
> on this JIRA, so the reference is bogus.
>
> Now that you know my thoughts on this approach, I'd like to hear your
> comments and ideas. If agreeable, then I'd also like to solicit volunteers
> to get this cleaned up.
>
> Thanks,
> Kevin
>
> [1]
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_2.0_incompatibilities
> [2]
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#migration_detach_behavior
>

JIRA references in documentation?

2009-11-24T07:16:01Z

Hi,
While I was looking for some information in our documentation in trunk, I
came across several references to JIRAs. The section on Incompatibilities
[1] really stuck out for me. I'm not thrilled with this approach. For a
few reasons...

o It forces customers to go find some other tool (JIRA) to look up
additional information. We've found several Users and even some Dev mailing
list contributors that don't know anything about JIRA.

o It makes us look "lazy". Instead of completing the documentation, we're
telling customers to go on a scavenger hunt.

o Some of the references are basically worthless. For example, in the
section on detach [2], there is a reference to OPENJPA-1215 for more
testcases that document the situation. But, there are no patches or commits
on this JIRA, so the reference is bogus.

Now that you know my thoughts on this approach, I'd like to hear your
comments and ideas. If agreeable, then I'd also like to solicit volunteers
to get this cleaned up.

Thanks,
Kevin

[1]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_2.0_incompatibilities
[2]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#migration_detach_behavior

[jira] Updated: (OPENJPA-1400) Unable to persist a relationship to a detached Entity

2009-11-23T14:21:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis updated OPENJPA-1400:
---------------------------------

Attachment: decompiled_entities.zip
OPENJPA-1400.patch

Attaching code changes, test case, and decompiled Entities.

> Unable to persist a relationship to a detached Entity
> ------------------------------------------------------
>
> Key: OPENJPA-1400
> URL: https://issues.apache.org/jira/browse/OPENJPA-1400
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.2.1, 2.0.0-M3
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Attachments: decompiled_entities.zip, OPENJPA-1400.patch
>
>
> I ran into a problem where OpenJPA is unable to persist a relationship from an attached Entity to a detached Entity. The problem occurs if the detached Entity does not have a DetachedState {openjpa.DetachState=loaded(DetachedStateField=false)} and the version is zero. When trying to flush the scenario described, the following exception is thrown by OpenJPA:
> <openjpa-2.0.0-SNAPSHOT-r422266:882172M nonfatal user error> org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged object in persistent field "org.apache.openjpa.persistence.detachment.model.NoDetachedStateEntityFieldAccess.relationship" during flush. However, this field does not allow cascade persist. Set the cascade attribute for this field to CascadeType.PERSIST or CascadeType.ALL (JPA annotations) or "persist" or "all" (JPA orm.xml), or enable cascade-persist globally, or manually persist the related field value prior to flushing. You cannot flush unmanaged objects or graphs that have persistent associations to unmanaged objects.
> This scenario should work, but OpenJPA incorrectly determines that the detached Entity was never actually a part of a persistence context. If version field is anything other than zero the flush of the relationship works as expected. This problem is in the enhanced bytecode we assume that when no StateManager is present a version of zero means that an Entity isn't detached.
> // Decompiled Entity bytecode
> public Boolean pcIsDetached()
> {
> if(pcStateManager != null)
> if(pcStateManager.isDetached())
> return Boolean.TRUE;
> else
> return Boolean.FALSE;
> if(pcGetDetachedState() != null && pcGetDetachedState() != PersistenceCapable.DESERIALIZED)
> return Boolean.TRUE;
> if(_version != 0)
> return Boolean.TRUE;
> else
> return Boolean.FALSE;
> }
> I will attach a patch which recreates this problem and also provides a solution. My solution to this problem is to add a boolean to the enhanced bytecode to keep track of whether or not the version field has been set. This fixes the problem for most cases, but there are still holes. In addition to the patch, I'll also post two decompiled Entities. One of those is enhanced with the existing code and the other is with my proposed changes.
> Notes:
> - For the sake of time, I did not fix this problem when using unenhanced classes.
> - This problem still exists if the detached Entity has been serialized at any point.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1400) Unable to persist a relationship to a detached Entity

2009-11-23T14:19:39Z

Unable to persist a relationship to a detached Entity
------------------------------------------------------

Key: OPENJPA-1400
URL: https://issues.apache.org/jira/browse/OPENJPA-1400
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0-M3, 1.2.1
Reporter: Rick Curtis
Assignee: Rick Curtis

I ran into a problem where OpenJPA is unable to persist a relationship from an attached Entity to a detached Entity. The problem occurs if the detached Entity does not have a DetachedState {openjpa.DetachState=loaded(DetachedStateField=false)} and the version is zero. When trying to flush the scenario described, the following exception is thrown by OpenJPA:

<openjpa-2.0.0-SNAPSHOT-r422266:882172M nonfatal user error> org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged object in persistent field "org.apache.openjpa.persistence.detachment.model.NoDetachedStateEntityFieldAccess.relationship" during flush. However, this field does not allow cascade persist. Set the cascade attribute for this field to CascadeType.PERSIST or CascadeType.ALL (JPA annotations) or "persist" or "all" (JPA orm.xml), or enable cascade-persist globally, or manually persist the related field value prior to flushing. You cannot flush unmanaged objects or graphs that have persistent associations to unmanaged objects.

This scenario should work, but OpenJPA incorrectly determines that the detached Entity was never actually a part of a persistence context. If version field is anything other than zero the flush of the relationship works as expected. This problem is in the enhanced bytecode we assume that when no StateManager is present a version of zero means that an Entity isn't detached.
// Decompiled Entity bytecode
public Boolean pcIsDetached()
{
if(pcStateManager != null)
if(pcStateManager.isDetached())
return Boolean.TRUE;
else
return Boolean.FALSE;
if(pcGetDetachedState() != null && pcGetDetachedState() != PersistenceCapable.DESERIALIZED)
return Boolean.TRUE;
if(_version != 0)
return Boolean.TRUE;
else
return Boolean.FALSE;
}

I will attach a patch which recreates this problem and also provides a solution. My solution to this problem is to add a boolean to the enhanced bytecode to keep track of whether or not the version field has been set. This fixes the problem for most cases, but there are still holes. In addition to the patch, I'll also post two decompiled Entities. One of those is enhanced with the existing code and the other is with my proposed changes.

Notes:
- For the sake of time, I did not fix this problem when using unenhanced classes.
- This problem still exists if the detached Entity has been serialized at any point.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

OpenJPA DataCache.writeLock()

2009-11-23T04:35:51Z

Hi all,
I'm currently working on fixing an issue with the EhCache OpenJPA
cache provider.
Doing so I ran across the DataCache.writeLock() and writeUnlock()
methods, which puzzled me a bit. From the naming, I'd like to think
that owning the write lock, I'll be the only thread mutating the
cache, yet current implementations I've seen seem to prove me wrong
(in internal usages e.g.
org.apache.openjpa.kernel.BrokerImpl.evict(Object, OpCallbacks): void
or API usages, but the latter could be more of wrong usages as well).
Anyways, as I haven't found any docs, can someone enlighten me on the
usage of these methods or point me to some literature ?
Thanks,
Alex

--
Alex Snaps <[hidden email]>
Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps

[jira] Commented: (OPENJPA-1399) NoResultException results in the complete transaction being rollled back

2009-11-23T03:11:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781363#action_12781363 ]

Amit Puri commented on OPENJPA-1399:
------------------------------------

Some more logs:

2009-11-18 18:53:26,671 ERROR [SessionHelper] error in ***** method
<openjpa-1.2.1-r2180:4612 nonfatal user error> org.apache.openjpa.persistence.NoResultException: The query on candidate type "class -------.entities.Session" with filter "select s from Session s where ---- = :-- AND ---- IS NULL and -------- ='1'" was configured to have a unique result, but no instance matched the query.
at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1299)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:848)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:779)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:254)
at org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:317)
at ------.helper.sessionmgmt.SessionHelper.signOn(SessionHelper.java:55)
at ------.ejb.sessionbean.sessionmgmt.SessionManagement.signOn(SessionManagement.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
2009-11-18 18:53:32,546 INFO [Transaction] TX Required: Committing transaction org.apache.geronimo.transaction.manager.TransactionImpl@6c396c39
2009-11-18 18:53:33,765 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back
<openjpa-1.2.1-r2180:4612 fatal general error> org.apache.openjpa.persistence.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:2163)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
Caused by:
<openjpa-1.2.1-r2180:4612 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=158, COLNO=0, DRIVER=3.50.152
..
..
FailedObject: --------.entities.Session@5c8d5c8d
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
at org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionary.java:503)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
... 24 more
Caused by:
org.apache.openjpa.lib.jdbc.ReportingSQLException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=158, COLNO=0, DRIVER=3.50.152
..
..
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
... 32 more
NestedThrowables:
<openjpa-1.2.1-r2180:4612 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=639, COLNO=0, DRIVER=3.50.152

FailedObject: -------.entities.SignOnTransaction@36f536f5
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
at org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionary.java:503)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
Caused by:
org.apache.openjpa.lib.jdbc.ReportingSQLException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=639, COLNO=0, DRIVER=3.50.152

at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
... 32 more
NestedThrowables:
com.ibm.db2.jcc.b.lm: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=639, COLNO=0, DRIVER=3.50.152
at com.ibm.db2.jcc.b.wc.a(wc.java:575)
at com.ibm.db2.jcc.b.wc.a(wc.java:57)
at com.ibm.db2.jcc.b.wc.a(wc.java:126)
at com.ibm.db2.jcc.b.tk.b(tk.java:1593)
at com.ibm.db2.jcc.b.tk.c(tk.java:1576)
at com.ibm.db2.jcc.t4.db.k(db.java:353)
at com.ibm.db2.jcc.t4.db.a(db.java:59)
at com.ibm.db2.jcc.t4.t.a(t.java:50)
at com.ibm.db2.jcc.t4.tb.b(tb.java:200)
at com.ibm.db2.jcc.b.uk.Gb(uk.java:2355)
at com.ibm.db2.jcc.b.uk.e(uk.java:3129)
at com.ibm.db2.jcc.b.uk.zb(uk.java:568)
at com.ibm.db2.jcc.b.uk.executeUpdate(uk.java:551)
at org.tranql.connector.jdbc.PreparedStatementHandle.executeUpdate(PreparedStatementHandle.java:103)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:864)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
<openjpa-1.2.1-r2180:4612 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=579, COLNO=0, DRIVER=3.50.152

FailedObject: -------.entities.ControlTransaction@36e936e9
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
at org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(DB2Dictionary.java:503)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
Caused by:
org.apache.openjpa.lib.jdbc.ReportingSQLException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=579, COLNO=0, DRIVER=3.50.152

at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
... 32 more
NestedThrowables:
com.ibm.db2.jcc.b.lm: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=579, COLNO=0, DRIVER=3.50.152
at com.ibm.db2.jcc.b.wc.a(wc.java:575)
at com.ibm.db2.jcc.b.wc.a(wc.java:57)
at com.ibm.db2.jcc.b.wc.a(wc.java:126)
at com.ibm.db2.jcc.b.tk.b(tk.java:1593)
at com.ibm.db2.jcc.b.tk.c(tk.java:1576)
at com.ibm.db2.jcc.t4.db.k(db.java:353)
at com.ibm.db2.jcc.t4.db.a(db.java:59)
at com.ibm.db2.jcc.t4.t.a(t.java:50)
at com.ibm.db2.jcc.t4.tb.b(tb.java:200)
at com.ibm.db2.jcc.b.uk.Gb(uk.java:2355)
at com.ibm.db2.jcc.b.uk.e(uk.java:3129)
at com.ibm.db2.jcc.b.uk.zb(uk.java:568)
at com.ibm.db2.jcc.b.uk.executeUpdate(uk.java:551)
at org.tranql.connector.jdbc.PreparedStatementHandle.executeUpdate(PreparedStatementHandle.java:103)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:864)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
at org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203)
at org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
at org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
2009-11-18 18:53:33,875 WARN [Transaction] Error ending association for XAResource org.apache.geronimo.transaction.manager.WrapperNamedXAResource@ba10ba1; transaction will roll back. XA error code: 100
com.ibm.db2.jcc.b.ym: [jcc][t4][10401][12066][3.50.152] XA exception: XA_RBROLLBACK ERRORCODE=-4228, SQLSTATE=null
at com.ibm.db2.jcc.b.wc.c(wc.java:402)
at com.ibm.db2.jcc.t4.ac.a(ac.java:1680)
at com.ibm.db2.jcc.t4.ac.end(ac.java:571)
at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.end(WrapperNamedXAResource.java:51)
at org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:571)
at org.apache.geronimo.transaction.manager.TransactionImpl.endResources(TransactionImpl.java:550)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:401)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
2009-11-18 18:53:33,890 INFO [Transaction] The transaction has been rolled back rather than commited: Unable to commit: transaction marked for rollback
2009-11-18 18:53:33,890 DEBUG [ejb] EJB REQUEST: EJB_OBJECT.BUSINESS_METHOD:***.jar/---:----:null -- RESPONSE: EJB_APP_EXCEPTION:javax.transaction.TransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback

> NoResultException results in the complete transaction being rollled back
> ------------------------------------------------------------------------
>
> Key: OPENJPA-1399
> URL: https://issues.apache.org/jira/browse/OPENJPA-1399
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 1.2.1
> Environment: Windows, Geronimo 214, DB2
> Reporter: Amit Puri
>
> One of my query which throws a NoResultException results in the complete transaction being rollled back.
> Here is the exception trace.
> -------------------------------------------------------------------------------------------
> 2009-11-18 18:53:26,671 ERROR [SessionHelper] error in ***** method
> <openjpa-1.2.1-r2180:4612 nonfatal user error> org.apache.openjpa.persistence.NoResultException: The query on candidate type "class -------.entities.Session" with filter "select s from Session s where ---- = :-- AND ---- IS NULL and -------- ='1'" was configured to have a unique result, but no instance matched the query.
> at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1299)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:848)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:779)
> at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:254)
> at org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:317)
> at ------.helper.sessionmgmt.SessionHelper.signOn(SessionHelper.java:55)
> at ------.ejb.sessionbean.sessionmgmt.SessionManagement.signOn(SessionManagement.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
> at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
> at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
> at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
> at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
> at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
> at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
> at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
> at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
> at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
> at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
> at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:735)
> 2009-11-18 18:53:32,546 INFO [Transaction] TX Required: Committing transaction org.apache.geronimo.transaction.manager.TransactionImpl@6c396c39
> 2009-11-18 18:53:33,765 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back
> <openjpa-1.2.1-r2180:4612 fatal general error> org.apache.openjpa.persistence.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:2163)
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
> at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
> at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
> at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
> at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
> at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
> at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
> at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
> at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
> at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
> at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
> at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
> at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
> at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
> at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
> at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
> at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
> at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
> at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:735)
> Caused by:
> <openjpa-1.2.1-r2180:4612 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=158, COLNO=0, DRIVER=3.50.152
> -------------------------------------------------------------------------------------------
> I find the following in JPA spec which clearly says that NoResultException should not result in a roll back.
> For your reference here is the section 3.7 of JPA spec from my copy.
> Section 3.7 of the JPA 1.0 spec states that:
> ------------------------------------------------------------------------------------------
> PersistenceException
> The PersistenceException is thrown by the persistence provider when a problem
> occurs. It may be thrown to report that the invoked operation could not complete because of an
> unexpected error (e.g., failure of the persistence provider to open a database connection).
> All other exceptions defined by this specification are subclasses of the PersistenceException.
> All instances of PersistenceException except for instances of NoResultException
> and NonUniqueResultException will cause the current transaction,
> if one is active, to be marked for rollback.
> -------------------------------------------------------------------------------------------

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1399) NoResultException results in the complete transaction being rollled back

2009-11-23T03:09:39Z

NoResultException results in the complete transaction being rollled back
------------------------------------------------------------------------

Key: OPENJPA-1399
URL: https://issues.apache.org/jira/browse/OPENJPA-1399
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 1.2.1
Environment: Windows, Geronimo 214, DB2
Reporter: Amit Puri

One of my query which throws a NoResultException results in the complete transaction being rollled back.

Here is the exception trace.

-------------------------------------------------------------------------------------------
2009-11-18 18:53:26,671 ERROR [SessionHelper] error in ***** method
<openjpa-1.2.1-r2180:4612 nonfatal user error> org.apache.openjpa.persistence.NoResultException: The query on candidate type "class -------.entities.Session" with filter "select s from Session s where ---- = :-- AND ---- IS NULL and -------- ='1'" was configured to have a unique result, but no instance matched the query.
at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1299)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:848)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:779)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:254)
at org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:317)
at ------.helper.sessionmgmt.SessionHelper.signOn(SessionHelper.java:55)
at ------.ejb.sessionbean.sessionmgmt.SessionManagement.signOn(SessionManagement.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
2009-11-18 18:53:32,546 INFO [Transaction] TX Required: Committing transaction org.apache.geronimo.transaction.manager.TransactionImpl@6c396c39
2009-11-18 18:53:33,765 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back
<openjpa-1.2.1-r2180:4612 fatal general error> org.apache.openjpa.persistence.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:2163)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2010)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1826)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:522)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:507)
at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:260)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138)
at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:896)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:735)
Caused by:
<openjpa-1.2.1-r2180:4612 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=2, TABLEID=158, COLNO=0, DRIVER=3.50.152
-------------------------------------------------------------------------------------------

I find the following in JPA spec which clearly says that NoResultException should not result in a roll back.

For your reference here is the section 3.7 of JPA spec from my copy.

Section 3.7 of the JPA 1.0 spec states that:
------------------------------------------------------------------------------------------
PersistenceException
The PersistenceException is thrown by the persistence provider when a problem
occurs. It may be thrown to report that the invoked operation could not complete because of an
unexpected error (e.g., failure of the persistence provider to open a database connection).
All other exceptions defined by this specification are subclasses of the PersistenceException.
All instances of PersistenceException except for instances of NoResultException
and NonUniqueResultException will cause the current transaction,
if one is active, to be marked for rollback.
-------------------------------------------------------------------------------------------

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-1398) Inheritance with Listgetter Bug

2009-11-24T01:28:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781835#action_12781835 ]

Stefan Wokusch commented on OPENJPA-1398:
-----------------------------------------

After long debug sessions i think i found the problem.
First I have to say, in many parts there is no Doku, so its very hard to find out what jpa does.

When jpa should load the t2list attribute, it first creates a correct query for getting the T3 values as well. But than it says, the query is not required and ignores the query. Giving here true is the first position to a possible bug (no doku about the seld variable, so i dont know what it does).
Than i found out, that the proxy creates a second query. This time it is the executed wrong query. When adding an Field in T3 like String text, the query would get the t3.text in the select statement, but dont make the where clause correct. So possible in the selectSubClasses method could be an error.
The third and the last possible reason is, that the select funktion inside the unionJoin of the proxy says, that the query is joinable, so it pushes the wrong where statement into the query. So the possible bug could be caused by this function.

After switching off the superclassDiscriminatorStrategyByDefault the test passes correctly. So the #1200 Ticket could cause this problem. The documentation says nothing, and it says the default of this attribute is false, but its true. So adding into persistence.xml
<property name="openjpa.Compatibility" value="... , superclassDiscriminatorStrategyByDefault=false"/>
fixes this problem. I dont know what this should do, but without that default value it works...

So, plz document the Compatibillity attributes, to make it much more easier :)

ps.:
After adding some other Compatibillity attributes openjpa works with the deadlock patch and a little hacks to remove orphans fine.

> Inheritance with Listgetter Bug
> -------------------------------
>
> Key: OPENJPA-1398
> URL: https://issues.apache.org/jira/browse/OPENJPA-1398
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa, kernel, query
> Affects Versions: 2.0.0-M3
> Environment: Vista 64bit, Mysql,
> Reporter: Stefan Wokusch
> Priority: Critical
>
> I have a Problem with my OpenJPA, and i think its a bug. The Getter/Proxy dont get all elements of a List.
> Following the complete Testcase scenario:
> For the test the following Settings are used. Cache have to be disabled, otherwise the test will pass because cached data.
> persistence.xml::
> ...
> <class>hellojpa.T1</class>
> <class>hellojpa.T2</class>
> <class>hellojpa.T3</class>
> <properties>
> <property name="openjpa.Log" value="SQL=TRACE"/>
> <property name="openjpa.OrphanedKeyAction" value="log(Channel=Orphans, Level=TRACE)"/>
> <property name="openjpa.Multithreaded" value="true" />
> <property name="openjpa.InverseManager" value="true"/>
> <property name="openjpa.LockManager" value="none"/>
> <property name="openjpa.WriteLockLevel" value="none"/>
> <property name="openjpa.Compatibility" value="QuotedNumbersInQueries=true,CopyOnDetach=true"/>
> <property name="openjpa.DetachState" value="fetch-groups"/>
> <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
> // Using Mysql but i think the prob is the query it selves :)
> <property name="openjpa.ConnectionURL" value="jdbc:mysql://localhost/jpatest" />
> <property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver" />
> <property name="openjpa.ConnectionUserName" value="jpatest" />
> <property name="openjpa.ConnectionPassword" value="XXXXXXXXX" />
> </properties>
> ...
> My Entityclasses:
> @Entity
> @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
> public class T1 {
> @Id
> @GeneratedValue
> private Integer id;
> public void setId(Integer id) {
> this.id = id;
> }
> public Integer getId() {
> return id;
> }
> }
> @Entity
> public class T2 extends T1{
> @OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.PERSIST)
> private List<T2> t2List;
> public void setT1List(List<T2> t2List) {
> this.t2List = t2List;
> }
> public List<T2> getT2List() {
> return t2List;
> }
> }
> @Entity
> public class T3 extends T2 {
> }
> We have 3 Classes on the top of each other, at the middle a List with T2s.
> My Testclasses:
> private static void commit(){
> em.getTransaction().begin();
> em.getTransaction().commit();
> }
> // Create a TestEntity
> T2 t2 = new T2();
> em.persist(t2);
> commit();
> // Put a T2
> t2.getT2List().add(new T2());
> commit();
> em.refresh(t2); // important to cause a new DB-Query.
> assert(t2.getT2List().size()==1); // its *OK*
> // Put a T3
> t2.getT2List().add(new T3());
> commit();
> em.refresh(t2); // important to cause a new DB-Query.
> assert(t2.getT2List().size()==2);// it *FAILS*
> Database after the Test:
> T1:
> id -> DTYPE
> 51 -> T2
> 52 -> T2
> 53 -> T3
> T1_T1
> T2_ID -> T2_T2LIST
> 51 -> 52
> 51 -> 53
> In the Database, there are both Elements correctly. I think the Problem is, that OpenJPA creates the following SQL-Queries:
> SELECT t1.id, t1.DTYPE
> FROM T1_T1 t0 INNER JOIN T1 t1 ON t0.T2_ID = t1.id
> WHERE t0.T2_ID = ? AND *t1.DTYPE = ? *
> [params=(int) 3601, (String) *T2*]
> So the T3 Entities would be ignored. in this query. Did anyone have an Idea why jpa makes such a strange query with ignoring the subclasses of T2.
> My other trys:
> - Marks with @Nonpolymorphic(NonpolymorphicType.JOINABLE)
> - Marks with @ElementNonpolymorphic(NonpolymorphicType.JOINABLE)
> - Take Set instead of List
> - The Scenario without a List and a Single Relation would pass and gets an query with t1.DTYPE IN (T2, T3). So its only with Lists.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1398) Inheritance with Listgetter Bug

2009-11-23T02:35:39Z

Inheritance with Listgetter Bug
-------------------------------

Key: OPENJPA-1398
URL: https://issues.apache.org/jira/browse/OPENJPA-1398
Project: OpenJPA
Issue Type: Bug
Components: jpa, kernel, query
Affects Versions: 2.0.0-M3
Environment: Vista 64bit, Mysql,
Reporter: Stefan Wokusch
Priority: Critical

I have a Problem with my OpenJPA, and i think its a bug. The Getter/Proxy dont get all elements of a List.
Following the complete Testcase scenario:

For the test the following Settings are used. Cache have to be disabled, otherwise the test will pass because cached data.
persistence.xml::
...
<class>hellojpa.T1</class>
<class>hellojpa.T2</class>
<class>hellojpa.T3</class>
<properties>
<property name="openjpa.Log" value="SQL=TRACE"/>
<property name="openjpa.OrphanedKeyAction" value="log(Channel=Orphans, Level=TRACE)"/>

<property name="openjpa.Multithreaded" value="true" />
<property name="openjpa.InverseManager" value="true"/>
<property name="openjpa.LockManager" value="none"/>
<property name="openjpa.WriteLockLevel" value="none"/>
<property name="openjpa.Compatibility" value="QuotedNumbersInQueries=true,CopyOnDetach=true"/>

<property name="openjpa.DetachState" value="fetch-groups"/>
<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
// Using Mysql but i think the prob is the query it selves :)
<property name="openjpa.ConnectionURL" value="jdbc:mysql://localhost/jpatest" />
<property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver" />
<property name="openjpa.ConnectionUserName" value="jpatest" />
<property name="openjpa.ConnectionPassword" value="XXXXXXXXX" />
</properties>
...

My Entityclasses:
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class T1 {
@Id
@GeneratedValue
private Integer id;
public void setId(Integer id) {
this.id = id;
}

public Integer getId() {
return id;
}
}
@Entity
public class T2 extends T1{
@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.PERSIST)
private List<T2> t2List;

public void setT1List(List<T2> t2List) {
this.t2List = t2List;
}

public List<T2> getT2List() {
return t2List;
}
}
@Entity
public class T3 extends T2 {
}

We have 3 Classes on the top of each other, at the middle a List with T2s.

My Testclasses:
private static void commit(){
em.getTransaction().begin();
em.getTransaction().commit();
}

// Create a TestEntity
T2 t2 = new T2();
em.persist(t2);
commit();

// Put a T2
t2.getT2List().add(new T2());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==1); // its *OK*

// Put a T3
t2.getT2List().add(new T3());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==2);// it *FAILS*

Database after the Test:
T1:
id -> DTYPE
51 -> T2
52 -> T2
53 -> T3
T1_T1
T2_ID -> T2_T2LIST
51 -> 52
51 -> 53

In the Database, there are both Elements correctly. I think the Problem is, that OpenJPA creates the following SQL-Queries:
SELECT t1.id, t1.DTYPE
FROM T1_T1 t0 INNER JOIN T1 t1 ON t0.T2_ID = t1.id
WHERE t0.T2_ID = ? AND *t1.DTYPE = ? *
[params=(int) 3601, (String) *T2*]

So the T3 Entities would be ignored. in this query. Did anyone have an Idea why jpa makes such a strange query with ignoring the subclasses of T2.

My other trys:
- Marks with @Nonpolymorphic(NonpolymorphicType.JOINABLE)
- Marks with @ElementNonpolymorphic(NonpolymorphicType.JOINABLE)
- Take Set instead of List
- The Scenario without a List and a Single Relation would pass and gets an query with t1.DTYPE IN (T2, T3). So its only with Lists.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Inheritance with Listgetter Bug

2009-11-20T17:17:36Z

Hello,
I have a Problem with my OpenJPA, and i think its a bug. The Getter/Proxy dont get all elements of a List.
Following the complete Testcase scenario:

For the test the following Settings are used. Cache have to be disabled, otherwise the test will pass because cached data.
persistence.xml::
...
<class>hellojpa.T1</class>
<class>hellojpa.T2</class>
<class>hellojpa.T3</class>
<properties>
<property name="openjpa.Log" value="SQL=TRACE"/>
<property name="openjpa.OrphanedKeyAction" value="log(Channel=Orphans, Level=TRACE)"/>

<property name="openjpa.Multithreaded" value="true" />
<property name="openjpa.InverseManager" value="true"/>
<property name="openjpa.LockManager" value="none"/>
<property name="openjpa.WriteLockLevel" value="none"/>
<property name="openjpa.Compatibility" value="QuotedNumbersInQueries=true,CopyOnDetach=true"/>

<property name="openjpa.DetachState" value="fetch-groups"/>
<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
// Using Mysql but i think the prob is the query it selves :)
<property name="openjpa.ConnectionURL" value="jdbc:mysql://localhost/jpatest" />
<property name="openjpa.ConnectionDriverName" value="com.mysql.jdbc.Driver" />
<property name="openjpa.ConnectionUserName" value="jpatest" />
<property name="openjpa.ConnectionPassword" value="XXXXXXXXX" />
</properties>
...

My Entityclasses:
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class T1 {
@Id
@GeneratedValue
private Integer id;
public void setId(Integer id) {
this.id = id;
}

public Integer getId() {
return id;
}
}
@Entity
public class T2 extends T1{
@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.PERSIST)
private List<T2> t2List;

public void setT1List(List<T2> t2List) {
this.t2List = t2List;
}

public List<T2> getT2List() {
return t2List;
}
}
@Entity
public class T3 extends T2 {
}

We have 3 Classes on the top of each other, at the middle a List with T2s.

My Testclasses:
private static void commit(){
em.getTransaction().begin();
em.getTransaction().commit();
}

// Create a TestEntity
T2 t2 = new T2();
em.persist(t2);
commit();

// Put a T2
t2.getT2List().add(new T2());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==1); // its *OK*

// Put a T3
t2.getT2List().add(new T3());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==2);// it *FAILS*

Database after the Test:
T1:
id -> DTYPE
51 -> T2
52 -> T2
53 -> T3
T1_T1
T2_ID -> T2_T2LIST
51 -> 52
51 -> 53

In the Database, there are both Elements correctly. I think the Problem is, that OpenJPA creates the following SQL-Queries:
SELECT t1.id, t1.DTYPE
FROM T1_T1 t0 INNER JOIN T1 t1 ON t0.T2_ID = t1.id
WHERE t0.T2_ID = ? AND *t1.DTYPE = ? *
[params=(int) 3601, (String) *T2*]

So the T3 Entities would be ignored. in this query. Did anyone have an Idea why jpa makes such a strange query with ignoring the subclasses of T2.

My other trys:
- Marks with @Nonpolymorphic(NonpolymorphicType.JOINABLE)
- Marks with @ElementNonpolymorphic(NonpolymorphicType.JOINABLE)
- Take Set instead of List
- The Scenario without a List and a Single Relation would pass and gets an query with t1.DTYPE IN (T2, T3). So its only with Lists.

Hope for help
Stefan

Inheritance with Listgetter Bug

2009-11-20T17:07:47Z

Hello Team,
I have a Problem with my OpenJPA, and i think its a bug. The
Getter/Proxy dont get all elements of a List.
Following the complete Testcase scenario:

For the test the following Settings are used. Cache have to be disabled,
otherwise the test will pass because cached data.
persistence.xml::
...
<class>hellojpa.T1</class>
<class>hellojpa.T2</class>
<class>hellojpa.T3</class>
<properties>
<property name="openjpa.Log" value="SQL=TRACE"/>
<property name="openjpa.OrphanedKeyAction"
value="log(Channel=Orphans, Level=TRACE)"/>

<property name="openjpa.Multithreaded" value="true" />
<property name="openjpa.InverseManager" value="true"/>
<property name="openjpa.LockManager" value="none"/>
<property name="openjpa.WriteLockLevel" value="none"/>
<property name="openjpa.Compatibility"
value="QuotedNumbersInQueries=true,CopyOnDetach=true"/>

<property name="openjpa.DetachState" value="fetch-groups"/>
<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
// Using Mysql but i think the prob is the query it selves :)
<property name="openjpa.ConnectionURL"
value="jdbc:mysql://localhost/jpatest" />
<property name="openjpa.ConnectionDriverName"
value="com.mysql.jdbc.Driver" />
<property name="openjpa.ConnectionUserName" value="jpatest" />
<property name="openjpa.ConnectionPassword" value="XXXXXXXXX" />
</properties>
...

My Entityclasses:
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class T1 {
@Id
@GeneratedValue
private Integer id;

public void setId(Integer id) {
this.id = id;
}

public Integer getId() {
return id;
}
}
@Entity
public class T2 extends T1{

@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.PERSIST)
private List<T2> t2List;

public void setT1List(List<T2> t2List) {
this.t2List = t2List;
}

public List<T2> getT2List() {
return t2List;
}
}
@Entity
public class T3 extends T2 {

}

We have 3 Classes on the top of each other, at the middle a List with T2s.

My Testclasses:
private static void commit(){
em.getTransaction().begin();
em.getTransaction().commit();
}

// Create a TestEntity
T2 t2 = new T2();
em.persist(t2);
commit();

// Put a T2
t2.getT2List().add(new T2());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==1); // its *OK*

// Put a T3
t2.getT2List().add(new T3());
commit();
em.refresh(t2); // important to cause a new DB-Query.
assert(t2.getT2List().size()==2);// it *FAILS*

Database after the Test:
T1:
id -> DTYPE
51 -> T2
52 -> T2
53 -> T3
T1_T1
T2_ID -> T2_T2LIST
<http://localhost/phpmyadmin/sql.php?db=jpatest&table=t1_t1&token=1b8675e6aa2418688ccc524052b6ba27&sql_query=SELECT+%2A+FROM+%60t1_t1%60+ORDER+BY+%60t1_t1%60.%60T2LIST_ID%60+ASC>51
-> 52
51 -> 53

In the Database, there are both Elements correctly. I think the Problem
is, that OpenJPA creates the following SQL-Queries:
SELECT t1.id, t1.DTYPE
FROM T1_T1 t0 INNER JOIN T1 t1 ON t0.T2_ID = t1.id
WHERE t0.T2_ID = ? AND *t1.DTYPE = ? *
[params=(int) 3601, (String) *T2*]

So the T3 Entities would be ignored. in this query. Did anyone have an
Idea why jpa makes such a strange query with ignoring the subclasses of T2.

My other trys:
- Marks with @Nonpolymorphic(NonpolymorphicType.JOINABLE)
- Marks with @ElementNonpolymorphic(NonpolymorphicType.JOINABLE)
- Take Set instead of List
- The Scenario without a List and a Single Relation would pass and gets
an query with t1.DTYPE IN (T2, T3). So its only with Lists.

Hope for help
Stefan

Long strings are improperly mapped on Informix

2009-11-20T08:21:25Z

Using Openjpa 1.2.1, I found that String fields annotated with @Column
(length=4000) result in an attempt to create a column with VARCHAR(4000).
But informix limits the size of VARCHAR to 255. The column should use the
LVARCHAR type.

MyEntity.java:
@Entity
public class MyEntity {

@Id
private int id;

@Basic
@Column(length=4000)
private String description;

public int getId() {
return id;
}

public void setId(int value) {
id = value;
}

public String getDescription() {
return description;
}

public void setDescription(String value) {
description = value;
}
}}

persistence.xml:
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="isvi">

<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<class>jpa.test.isvi.MyEntity</class>
<properties>
<property name="openjpa.ConnectionDriverName"
value="com.ibm.db2.jcc.DB2Driver"/>
<property name="openjpa.ConnectionUserName" value="user
"/>
<property name="openjpa.ConnectionPassword" value="
password"/>
<property name="openjpa.ConnectionURL"
value="jdbc:informix-sqli://host:port/db"/>
<property name="openjpa.jdbc.SynchronizeMappings"
value="buildSchema(ForeignKeys=true)"/>
</properties>
</persistence-unit>
</persistence>

When I run the code and attempt to create the EntityManager object, I get
all of this in the console:
2737 isvi INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.1,
2951 isvi INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.InformixDictionary".
Exception in thread "main" <openjpa-1.2.1-r752877:753278 nonfatal general
error> org.apache.openjpa.persistence.PersistenceException: IDS SQL Error:
SQLCODE=-650, SQLSTATE=IX000, SQLERRMC=null, DRIVER=3.51.90 {stmnt
809054265 CREATE TABLE MyEntity (id INTEGER NOT NULL, description VARCHAR
(4000), PRIMARY KEY (id)) LOCK MODE ROW} [code=-650, state=IX000]
at org.apache.openjpa.jdbc.meta.MappingTool.record
(MappingTool.java:553)
at org.apache.openjpa.jdbc.meta.MappingTool.record
(MappingTool.java:453)
at
org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings
(JDBCBrokerFactory.java:159)
at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl
(JDBCBrokerFactory.java:119)
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker
(AbstractBrokerFactory.java:189))
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker
(DelegatingBrokerFactory.java:142)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager
(EntityManagerFactoryImpl.java:192)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager
(EntityManagerFactoryImpl.java:145)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager
(EntityManagerFactoryImpl.java:56))
at jpa.test.isvi.Main.run(Main.java:12)
at jpa.test.isvi.Main.main(Main.java:53)
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: IDS SQL
Error: SQLCODE=-650, SQLSTATE=IX000, SQLERRMC=null, DRIVER=3.51.90 {stmnt
809054265 CREATE TABLE MyEntity (id INTEGER NOT NULL, description VARCHAR
(4000), PRIMARY KEY (id)) LOCK MODE ROW} [code=-650, state=IX000]
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap
(LoggingConnectionDecorator.java:192)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700
(LoggingConnectionDecorator.java:57),
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator
$LoggingConnection$LoggingStatement.executeUpdate
(LoggingConnectionDecorator.java:762)
at org.apache.openjpa.lib.jdbc.DelegatingStatement.executeUpdate
(DelegatingStatement.java:114)
at org.apache.openjpa.jdbc.schema.SchemaTool.executeSQL
(SchemaTool.java:1191)
at org.apache.openjpa.jdbc.schema.SchemaTool.createTable
(SchemaTool.java:949)
at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:526)
at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:344)
at org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:321)
at org.apache.openjpa.jdbc.meta.MappingTool.record
(MappingTool.java:501):
... 10 more

As you can see the column definition for description is invalid. If I
reduce the length of the column 255, everything is OK. I cannot use a @Lob
annotation because this column needs to be searchable. Should this be
logged as a bug?

Marc Boudreau
Software Developer
IBM Cognos Content Manager
[hidden email]
Phone: 613-356-6412

[jira] Created: (OPENJPA-1397) NULL in columns part of an @IdClass composite key leads to "disappearing" (null) returned objects

2009-11-19T05:44:39Z

NULL in columns part of an @IdClass composite key leads to "disappearing" (null) returned objects
-------------------------------------------------------------------------------------------------

Key: OPENJPA-1397
URL: https://issues.apache.org/jira/browse/OPENJPA-1397
Project: OpenJPA
Issue Type: Bug
Components: jdbc, kernel
Affects Versions: 2.0.0-M3, 1.2.1
Reporter: Michael Vorburger
Attachments: openJPA_NullId.zip

As discussed on http://openjpa.markmail.org/search/?q=#query:list%3Aorg.apache.openjpa.users+page:1+mid:yua5kf7vd5m7wrnw+state:results, there is a bug in OpenJPA iff ... "any @Id field of a composite key mapped via an @IdClass identity is NULL" (enough keywords to allow future searching? ;).

The attached test case provides running code illustrating this with two simple entities and a failing JUnit.

While relational database do NOT appear to allow NULL value for columns which are part of a PRIMARY KEY CONSTRAINT, this kind of situation and mapping can (and in our case has!) occurred when mapping to legacy schemas with tables where a certain number / subset of columns are in fact the "logical" identifying set, without there being a physical PK constraint (nothing says you HAVE to have a physical PK). -- Both JPA Spec and OpenJPA doc make no statement if this is supposed to work or not work, they say nothing about this (as far as I could see; I checked before filing this; and nobody on the list made any statements re. this). It would be interesting to know if and how other JPA implementations handle this.

Assuming this is a small internal implementation bug and not a conceptual / design issue (note it's NOT the @IdClass instance that is null, it's only some fields within an Id, with others being available; and uniqueness of the combination guaranteed by data in DB of course!), it would be great if this could be make to work as one would naturally expect. (Or, at the very least, OpenJPA should fail and issue a clear error message, instead of just returning null; fix much better though.)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1397) NULL in columns part of an @IdClass composite key leads to "disappearing" (null) returned objects

2009-11-19T05:44:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Vorburger updated OPENJPA-1397:
---------------------------------------

Attachment: openJPA_NullId.zip

> NULL in columns part of an @IdClass composite key leads to "disappearing" (null) returned objects
> -------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-1397
> URL: https://issues.apache.org/jira/browse/OPENJPA-1397
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
> Affects Versions: 1.2.1, 2.0.0-M3
> Reporter: Michael Vorburger
> Attachments: openJPA_NullId.zip
>
>
> As discussed on http://openjpa.markmail.org/search/?q=#query:list%3Aorg.apache.openjpa.users+page:1+mid:yua5kf7vd5m7wrnw+state:results, there is a bug in OpenJPA iff ... "any @Id field of a composite key mapped via an @IdClass identity is NULL" (enough keywords to allow future searching? ;).
> The attached test case provides running code illustrating this with two simple entities and a failing JUnit.
> While relational database do NOT appear to allow NULL value for columns which are part of a PRIMARY KEY CONSTRAINT, this kind of situation and mapping can (and in our case has!) occurred when mapping to legacy schemas with tables where a certain number / subset of columns are in fact the "logical" identifying set, without there being a physical PK constraint (nothing says you HAVE to have a physical PK). -- Both JPA Spec and OpenJPA doc make no statement if this is supposed to work or not work, they say nothing about this (as far as I could see; I checked before filing this; and nobody on the list made any statements re. this). It would be interesting to know if and how other JPA implementations handle this.
> Assuming this is a small internal implementation bug and not a conceptual / design issue (note it's NOT the @IdClass instance that is null, it's only some fields within an Id, with others being available; and uniqueness of the combination guaranteed by data in DB of course!), it would be great if this could be make to work as one would naturally expect. (Or, at the very least, OpenJPA should fail and issue a clear error message, instead of just returning null; fix much better though.)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1396) metadata-complete in the orm file does not override @Transition annotation

2009-11-19T07:15:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fay Wang resolved OPENJPA-1396.
-------------------------------

Resolution: Fixed

> metadata-complete in the orm file does not override @Transition annotation
> ---------------------------------------------------------------------------
>
> Key: OPENJPA-1396
> URL: https://issues.apache.org/jira/browse/OPENJPA-1396
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 2.0.0
> Reporter: Fay Wang
> Assignee: Fay Wang
> Fix For: 2.0.0
>
>
> In the orm.xml:
> <embeddable class="embeddable.Address" metadata-complete="true"/
> where embeddable.Address is defined as:
> @Embeddable
> public class Address {
> @Transient
> protected String street;
> protected String city;
>
> protected String state;
> ...
> }
> According to the spec (12.2.5.1): "If the metadata-complete attribute of the embeddable element is specified as true, any annotations on the embeddable class (and its fields and properties) are ignored. When metadata-complete is specified as true and attributes and sub-elements of the embeddable element are omitted, the default values for those attributes and elements are applied.". However, the value of the street field in the Address class is not persistent.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1396) metadata-complete in the orm file does not override @Transition annotation

2009-11-18T22:00:40Z

metadata-complete in the orm file does not override @Transition annotation
---------------------------------------------------------------------------

Key: OPENJPA-1396
URL: https://issues.apache.org/jira/browse/OPENJPA-1396
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0
Reporter: Fay Wang
Assignee: Fay Wang
Fix For: 2.0.0

In the orm.xml:

<embeddable class="embeddable.Address" metadata-complete="true"/

where embeddable.Address is defined as:

@Embeddable
public class Address {
@Transient
protected String street;

protected String city;

protected String state;
...
}

According to the spec (12.2.5.1): "If the metadata-complete attribute of the embeddable element is specified as true, any annotations on the embeddable class (and its fields and properties) are ignored. When metadata-complete is specified as true and attributes and sub-elements of the embeddable element are omitted, the default values for those attributes and elements are applied.". However, the value of the street field in the Address class is not persistent.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1395) MappingTool attempts to create table in Oracle even when the table already exist

2009-11-18T15:41:39Z

MappingTool attempts to create table in Oracle even when the table already exist
--------------------------------------------------------------------------------

Key: OPENJPA-1395
URL: https://issues.apache.org/jira/browse/OPENJPA-1395
Project: OpenJPA
Issue Type: Bug
Components: tooling
Affects Versions: 2.0.0-M3, 2.0.0
Reporter: Albert Lee
Fix For: 2.0.0

When SynchronizedMapping property is used, MappingTool attempts to create table in Oracle even when the table already exist. When it happens, the following exception is thrown.

2203 test TRACE [main] openjpa.jdbc.SQL - <t 1183336072, conn 1912762882> executing prepstmnt 1956607135 SELECT SEQUENCE_OWNER AS SEQUENCE_SCHEMA, SEQUENCE_NAME FROM ALL_SEQUENCES
2203 test TRACE [main] openjpa.jdbc.SQL - <t 1183336072, conn 1912762882> [0 ms] spent
2422 test TRACE [main] openjpa.jdbc.SQL - <t 1183336072, conn 1594646284> executing stmnt 651896539 CREATE TABLE Department (id NUMBER NOT NULL, name VARCHAR2(255), PRIMARY KEY (id))
2437 test TRACE [main] openjpa.jdbc.SQL - <t 1183336072, conn 1594646284> [15 ms] spent
<openjpa-2.0.0-SNAPSHOT-r422266:881772M nonfatal general error> org.apache.openjpa.persistence.PersistenceException: ORA-00955: name is already used by an existing object
{stmnt 651896539 CREATE TABLE Department (id NUMBER NOT NULL, name VARCHAR2(255), PRIMARY KEY (id))} [code=955, state=42000]
at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:553)
at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:453)
at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:155)
at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:159)
at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:117)
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:202)
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:152)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:200)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:151)
at org.apache.openjpa.persistence.lockmgr.TestPessimisticLocks.setUp(TestPessimisticLocks.java:45)
at junit.framework.TestCase.runBare(TestCase.java:125)
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 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: ORA-00955: name is already used by an existing object
{stmnt 651896539 CREATE TABLE Department (id NUMBER NOT NULL, name VARCHAR2(255), PRIMARY KEY (id))} [code=955, state=42000]
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:254)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$3(LoggingConnectionDecorator.java:251)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingStatement.executeUpdate(LoggingConnectionDecorator.java:944)
at org.apache.openjpa.lib.jdbc.DelegatingStatement.executeUpdate(DelegatingStatement.java:136)
at org.apache.openjpa.jdbc.schema.SchemaTool.executeSQL(SchemaTool.java:1202)
at org.apache.openjpa.jdbc.schema.SchemaTool.createTable(SchemaTool.java:960)
at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:537)
at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:345)
at org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:322)
at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:501)
... 23 more

If the tables are manually drop, the create table works fine.

Albert Lee.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Draft proposal for a JSR-303 Bean Validation incubator podling

2009-11-18T13:02:13Z

We have an initial draft proposal to create a JSR-303 Bean Validation
implementation at Apache as an incubator podling.

Take a look at the proposal [1] and feel free to ask questions about it
on the dev@commons list and volunteer to be an initial committer if you
have time and interests in bean validation....

[1] http://wiki.apache.org/incubator/ValidationProposal

Thanks,
Donald

[jira] Resolved: (OPENJPA-1394) Pessimistic Lock not honour when ORDER BY clause is used

2009-11-19T15:39:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee resolved OPENJPA-1394.
---------------------------------

Resolution: Fixed
Fix Version/s: 2.0.0

> Pessimistic Lock not honour when ORDER BY clause is used
> --------------------------------------------------------
>
> Key: OPENJPA-1394
> URL: https://issues.apache.org/jira/browse/OPENJPA-1394
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Affects Versions: 2.0.0-M3, 2.0.0
> Reporter: Albert Lee
> Assignee: Albert Lee
> Fix For: 2.0.0
>
>
> query = em.createQuery(
> "select e.department from Employee e where e.id < 10 order by e.department.id").setFirstResult(3);
> query.setLockMode(LockModeType.PESSIMISTIC_READ);
> q = query.getResultList();
> yields the following SQL statement but with no lock on the Employee row:
> openjpa.Runtime: Info: The database is unable to lock this query. Each object matching the query will be locked individually after it is loaded; however, it is technically possible that another transaction could modify the data before the lock is obtained. See the documentation on Object Locking for details.
> "SELECT t1.ID, t1.NAME, t0.FK_DEPT FROM CTS1.EMPLOYEE t0 LEFT OUTER JOIN CTS1.DEPARTMENT t1 ON t0.FK_DEPT = t1.ID WHERE (t0.ID < CAST(? AS BIGINT)) ORDER BY t0.FK_DEPT ASC "
> openjpa.jdbc.SQL: Trace: <t 2035185998, conn 1784113751> executing prepstmnt 1845128698 SELECT t1.ID, t1.NAME, t0.FK_DEPT FROM CTS1.EMPLOYEE t0 LEFT OUTER JOIN CTS1.DEPARTMENT t1 ON t0.FK_DEPT = t1.ID WHERE (t0.ID < CAST(? AS BIGINT)) ORDER BY t0.FK_DEPT ASC [params=(long) 10]

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OPENJPA-1394) Pessimistic Lock not honour when ORDER BY clause is used

2009-11-19T15:39:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Albert Lee closed OPENJPA-1394.
-------------------------------

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1394) Pessimistic Lock not honour when ORDER BY clause is used

2009-11-18T07:38:39Z

Pessimistic Lock not honour when ORDER BY clause is used
--------------------------------------------------------

Key: OPENJPA-1394
URL: https://issues.apache.org/jira/browse/OPENJPA-1394
Project: OpenJPA
Issue Type: Bug
Components: query
Affects Versions: 2.0.0-M3, 2.0.0
Reporter: Albert Lee
Assignee: Albert Lee

query = em.createQuery(
"select e.department from Employee e where e.id < 10 order by e.department.id").setFirstResult(3);
query.setLockMode(LockModeType.PESSIMISTIC_READ);
q = query.getResultList();

yields the following SQL statement but with no lock on the Employee row:

openjpa.Runtime: Info: The database is unable to lock this query. Each object matching the query will be locked individually after it is loaded; however, it is technically possible that another transaction could modify the data before the lock is obtained. See the documentation on Object Locking for details.
"SELECT t1.ID, t1.NAME, t0.FK_DEPT FROM CTS1.EMPLOYEE t0 LEFT OUTER JOIN CTS1.DEPARTMENT t1 ON t0.FK_DEPT = t1.ID WHERE (t0.ID < CAST(? AS BIGINT)) ORDER BY t0.FK_DEPT ASC "
openjpa.jdbc.SQL: Trace: <t 2035185998, conn 1784113751> executing prepstmnt 1845128698 SELECT t1.ID, t1.NAME, t0.FK_DEPT FROM CTS1.EMPLOYEE t0 LEFT OUTER JOIN CTS1.DEPARTMENT t1 ON t0.FK_DEPT = t1.ID WHERE (t0.ID < CAST(? AS BIGINT)) ORDER BY t0.FK_DEPT ASC [params=(long) 10]

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1393) CriteriaBuilder.countDistinct() does not return correct result

2009-11-17T16:21:39Z

CriteriaBuilder.countDistinct() does not return correct result
--------------------------------------------------------------

Key: OPENJPA-1393
URL: https://issues.apache.org/jira/browse/OPENJPA-1393
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0-M3
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Fix For: 2.0.0-M4

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1392) CriteriaBuilder.size() must return Integer as value

2009-11-17T16:19:39Z

CriteriaBuilder.size() must return Integer as value
---------------------------------------------------

Key: OPENJPA-1392
URL: https://issues.apache.org/jira/browse/OPENJPA-1392
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0-M3
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Fix For: 2.0.0-M4

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1391) Handle generic/unspecified type arguments for persistent fields during metamodel generation

2009-11-17T12:44:39Z

Handle generic/unspecified type arguments for persistent fields during metamodel generation
--------------------------------------------------------------------------------------------

Key: OPENJPA-1391
URL: https://issues.apache.org/jira/browse/OPENJPA-1391
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0-M3
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Fix For: 2.0.0-M4

NPE thrown when metamodel generator encounters a untyped or wildcard type parameter in a collection-valued field

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1390) Criteria API untyped join(String attr) implies any attribute not a singular attribute

2009-11-17T10:07:39Z

Criteria API untyped join(String attr) implies any attribute not a singular attribute
-------------------------------------------------------------------------------------

Key: OPENJPA-1390
URL: https://issues.apache.org/jira/browse/OPENJPA-1390
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.0.0-M3
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Fix For: 2.0.0-M4

Untyped From.join(String attr) is unlike typed From.join() because the given attr in untyped version can be of any attribute type and not necessarily a singular attribute.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1389) Bad DELETE query generation with HsqlDB

2009-11-17T02:06:39Z

Bad DELETE query generation with HsqlDB
---------------------------------------

Key: OPENJPA-1389
URL: https://issues.apache.org/jira/browse/OPENJPA-1389
Project: OpenJPA
Issue Type: Bug
Affects Versions: 2.0.0-M3, 1.2.1
Environment: Windows XP, Java 1.6, HsqlDB 1.9.0-rc4, OpenJPA 1.2.1 and 2.0.0-M3
Reporter: Fabien Charlet

I use an object Log, mapped with a table LOG in HsqlDB.

When I try to execute a "DELETE FROM Log" query, I have an error
with the SQL code generated :

782 openjpa TRACE [main] openjpa.Query - Executing query: [DELETE
FROM Log l WHERE l.application = :application AND l.logDate < :aDate]
with parameters: {application=Isis, aDate=Tue Nov 17 10:12:26 CET
2009}
[KO] SimpleLogDAO.purgeLogs( Application@45d8241 Isis, Date@16a1227
Tue Nov 17 10:12:26 CET 2009 ) returned ReportingSQLException:
unexpected token: T0 {DELETE FROM LOG t0 WHERE (t0.APPLICATION_ID = ?
AND t0.LOG_DATE < ?)} [code=-5581, state=42581]
3782 openjpa TRACE [main] openjpa.jdbc.JDBC - <t 914454, conn
12437155> [0 ms] rollback
3782 openjpa TRACE [main] openjpa.jdbc.JDBC - <t 914454, conn
12437155> [0 ms] close

It seems that this HQL query generate "DELETE FROM LOG t0" but HsqlDB
doesn't suport a token after the table name in the delete statement.

Did I miss something ?

I use this mapping :

@Entity
@Table(name="LOG")
public class Log implements RestrictedObject, ICrudEntity {

@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private long id;

@Column(name="VERSION")
@Version
private int version;

@Column(name="USER")
private String user;

@OneToOne(fetch=FetchType.LAZY)
@JoinColumn(name="APPLICATION_ID", referencedColumnName="ID")
private Application application;

@Column(name="APPLICATION_VERSION")
private String applicationVersion;

@Column(name="NETWORK_INFORMATION")
private String networkInformation;

@Column(name="MESSAGE")

private String message;

@Column(name="LOG_DATE")
private Date logDate;

@OneToOne(fetch=FetchType.LAZY)
@JoinColumn(name="CATEGORY_ID", referencedColumnName="ID")
private Category category;

@Transient
private List<File> datas = new ArrayList<File>();

....
}

And I create the table in HsqlDB with this query :

statement.executeUpdate("CREATE TABLE LOG ( ID BIGINT GENERATED BY
DEFAULT AS IDENTITY(START WITH 1) PRIMARY KEY, " +
"VERSION INT," +
"USER VARCHAR(20)," +
"APPLICATION_ID BIGINT," +
"APPLICATION_VERSION VARCHAR(20)," +
"NETWORK_INFORMATION VARCHAR(40)," +
"MESSAGE VARCHAR(1000)," +
"LOG_DATE TIMESTAMP," +
"CATEGORY_ID BIGINT)");

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-1388) JPQL named parameter using a reserved word resulting in ArgumentException

2009-11-18T11:36:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Catalina Wei updated OPENJPA-1388:
----------------------------------

Affects Version/s: (was: 2.0.0)
1.3.0
Summary: JPQL named parameter using a reserved word resulting in ArgumentException (was: JPQL named parameter using a reserved word (:vlaue) resulting in ArgumentException)

Same fix applied to 1.3 branch

> JPQL named parameter using a reserved word resulting in ArgumentException
> -------------------------------------------------------------------------
>
> Key: OPENJPA-1388
> URL: https://issues.apache.org/jira/browse/OPENJPA-1388
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Affects Versions: 1.3.0
> Reporter: Catalina Wei
> Assignee: Catalina Wei
> Fix For: 2.0.0
>
>
> In JPA2, additional reserved words are introduced in the JPQL language. For example, KEY, VALUE, ENTRY, CASE, etc.
> These keywords is causing existing application that migrate to JPA2 regressed in ArgumentException (JPQL parser error).
> For example,
> JPQL: select c from Customer c where c.name = :value
> :value is a named parameter, but 'value' is a reserved word in JPA2.
> The above query used to work in OpenJPA-1.2.x but not in OpenJPA-2.x

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1388) JPQL named parameter using a reserved word (:vlaue) resulting in ArgumentException

2009-11-17T15:36:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Catalina Wei resolved OPENJPA-1388.
-----------------------------------

Resolution: Fixed
Fix Version/s: 2.0.0

Using reserved words as named parameter is allowed in JPQL query.

> JPQL named parameter using a reserved word (:vlaue) resulting in ArgumentException
> ----------------------------------------------------------------------------------
>
> Key: OPENJPA-1388
> URL: https://issues.apache.org/jira/browse/OPENJPA-1388
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Affects Versions: 2.0.0
> Reporter: Catalina Wei
> Assignee: Catalina Wei
> Fix For: 2.0.0
>
>
> In JPA2, additional reserved words are introduced in the JPQL language. For example, KEY, VALUE, ENTRY, CASE, etc.
> These keywords is causing existing application that migrate to JPA2 regressed in ArgumentException (JPQL parser error).
> For example,
> JPQL: select c from Customer c where c.name = :value
> :value is a named parameter, but 'value' is a reserved word in JPA2.
> The above query used to work in OpenJPA-1.2.x but not in OpenJPA-2.x

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-1388) JPQL named parameter using a reserved word (:vlaue) resulting in ArgumentException

2009-11-16T10:15:39Z

JPQL named parameter using a reserved word (:vlaue) resulting in ArgumentException
----------------------------------------------------------------------------------

Key: OPENJPA-1388
URL: https://issues.apache.org/jira/browse/OPENJPA-1388
Project: OpenJPA
Issue Type: Bug
Components: query
Affects Versions: 2.0.0
Reporter: Catalina Wei
Assignee: Catalina Wei

In JPA2, additional reserved words are introduced in the JPQL language. For example, KEY, VALUE, ENTRY, CASE, etc.
These keywords is causing existing application that migrate to JPA2 regressed in ArgumentException (JPQL parser error).
For example,

JPQL: select c from Customer c where c.name = :value

:value is a named parameter, but 'value' is a reserved word in JPA2.

The above query used to work in OpenJPA-1.2.x but not in OpenJPA-2.x

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r880689 - Build break

2009-11-16T07:50:59Z

Looking at it right now... will fix

Regards --

Pinaki

Donald Woods <[hidden email]>
11/16/2009 07:13 AM

To
[hidden email], Pinaki Poddar <[hidden email]>
cc

Subject
Re: svn commit: r880689 - Build break

Pinaki, it looks like the below changes are causing a compile failure -

[INFO] Compiling 343 source files to
/Users/drwoods/openjpa/trunk/openjpa-jdbc/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure

/Users/drwoods/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingDefaultsImpl.java:[542,17]

cannot find symbol
symbol : method addSubColumn(java.lang.String)
location: class org.apache.openjpa.jdbc.schema.Table

/Users/drwoods/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingDefaultsImpl.java:[544,13]

cannot find symbol
symbol : method resetSubColumns()
location: class org.apache.openjpa.jdbc.schema.Table

-Donald

[hidden email] wrote:
> Author: ppoddar
> Date: Mon Nov 16 09:33:29 2009
> New Revision: 880689
>
> URL: http://svn.apache.org/viewvc?rev=880689&view=rev
> Log:
> OPENJPA-1051: Simplify check for uniqueness of column names. Patch
contributed by Ravi Palacherla.
>
> Modified:
>
openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
>
> Modified:
openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
> URL:
http://svn.apache.org/viewvc/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java?rev=880689&r1=880688&r2=880689&view=diff

>
==============================================================================
> ---
openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
(original)
> +++
openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
Mon Nov 16 09:33:29 2009

> @@ -376,6 +376,13 @@
> return col;
> }
>
> + /**
> + * Add a name to this NameSet
> + */
> + public void addCorrectedColumnName(String name, boolean validate) {
> + addName(name, validate);
> + }
> +
>
> /**
> * Remove the given column from the table.
> @@ -816,15 +823,4 @@
> public void setColNumber(int colNum) {
> _colNum = colNum;
> }
> -
> - /**
> - * Add a column to the subNames set to avoid naming conflict.
> - */
> - public void addSubColumn(String name) {
> - addSubName(name);
> - }
> -
> - public void resetSubColumns() {
> - resetSubNames();
> - }
> }
>
>
>

Re: svn commit: r880689 - Build break

2009-11-16T05:13:22Z

Pinaki, it looks like the below changes are causing a compile failure -

[INFO] Compiling 343 source files to
/Users/drwoods/openjpa/trunk/openjpa-jdbc/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure

/Users/drwoods/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingDefaultsImpl.java:[542,17]
cannot find symbol
symbol : method addSubColumn(java.lang.String)
location: class org.apache.openjpa.jdbc.schema.Table

/Users/drwoods/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingDefaultsImpl.java:[544,13]
cannot find symbol
symbol : method resetSubColumns()
location: class org.apache.openjpa.jdbc.schema.Table

-Donald

[hidden email] wrote:

> Author: ppoddar
> Date: Mon Nov 16 09:33:29 2009
> New Revision: 880689
>
> URL: http://svn.apache.org/viewvc?rev=880689&view=rev
> Log:
> OPENJPA-1051: Simplify check for uniqueness of column names. Patch contributed by Ravi Palacherla.
>
> Modified:
> openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
>
> Modified: openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java
> URL: http://svn.apache.org/viewvc/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java?rev=880689&r1=880688&r2=880689&view=diff
> ==============================================================================
> --- openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java (original)
> +++ openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/Table.java Mon Nov 16 09:33:29 2009
> @@ -376,6 +376,13 @@
> return col;
> }
>
> + /**
> + * Add a name to this NameSet
> + */
> + public void addCorrectedColumnName(String name, boolean validate) {
> + addName(name, validate);
> + }
> +
>
> /**
> * Remove the given column from the table.
> @@ -816,15 +823,4 @@
> public void setColNumber(int colNum) {
> _colNum = colNum;
> }
> -
> - /**
> - * Add a column to the subNames set to avoid naming conflict.
> - */
> - public void addSubColumn(String name) {
> - addSubName(name);
> - }
> -
> - public void resetSubColumns() {
> - resetSubNames();
> - }
> }
>
>
>

[jira] Commented: (OPENJPA-1387) Unique colums automatically defined as non-nullable

2009-11-16T02:26:41Z

[ https://issues.apache.org/jira/browse/OPENJPA-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778287#action_12778287 ]

Martin Dirichs commented on OPENJPA-1387:
-----------------------------------------

Just noticed that there exists an exceptional database not capable of unique contraints on nullable fields: Apache Derby, versions up to 10.4.1.3. In 10.4.1.3, this shortcoming was fixed, see here:
http://issues.apache.org/jira/browse/DERBY-3330
OpenJPA currently uses Derby 10.2.2.0 for its test cases. Thus, there are build failures after applying this patch. There are three possibilities of how to deal with this:
1. Eliminate the problem by updating to a more recent Derby version.
2. Modify the test cases so that @Column(nullable=false) is explicitly stated where necessary.
3. Continue to label columns implicitly as non-nullable as database-specific logic. Do it for Derby < 10.4.1.3 and maybe some other database out there I am not aware of, leave it for all others (default).

> Unique colums automatically defined as non-nullable
> ---------------------------------------------------
>
> Key: OPENJPA-1387
> URL: https://issues.apache.org/jira/browse/OPENJPA-1387
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.0.0-M3
> Environment: Error happens in every environment.
> Reporter: Martin Dirichs
> Assignee: Pinaki Poddar
> Fix For: 2.0.0-M4
>
> Attachments: OpenJPA-Trunk_OJ1387.patch
>
>
> Any unique constraint declared with OpenJPA implicitly sets the respective columns to be non-null. This is a problem if OpenJPA's mapping tool is used to create the database schema. Even if something like @Column(nullable=true) is explicitly stated, the columns will always be created by OpenJPA as not null.
> Modifying the database schema manually to make the columns nullable is a possible workaround. It does not seem to cause any problems with either OpenJPA or the databases.
> I would suggest to drop the marking of unique columns as not nullable. This is done by removing the corresponding code lines in org.apache.openjpa.jdbc.schema.Unique (trivial patch appended to this issue). If someone wants a unique column to be not nullable, this can be specified explicitly with @Column(nullable=false) as usual.
> I can only speculate about the reason this strange coupling of unique and nullable had been introduced into OpenJPA. To my knowledge, it is perfectly legal use to have unique contraints on nullable columns. In effect this means that there may be multiple rows with null values, whilst all rows with non-null values have to be unique. ANSI SQL-92 also explicitly mentions nullable unique columns and states that this is a crucial difference between PRIMARY KEY columns and UNIQUE columns: the former are always not nullable, the latter may be nullable.
> This issue also pops up again and again in the user discussions, without (to my knowledge) a single authorative answer to why this behaviour is as it is in OpenJPA. Two examples:
> My question, which remained unanswered:
> http://n2.nabble.com/Unique-colums-automatically-made-NOT-NULL-td2827809.html
> Another users question, about a month later:
> http://n2.nabble.com/Nullable-unique-constraints-td3161182.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-1387) Unique colums automatically defined as non-nullable

2009-11-16T01:38:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pinaki Poddar resolved OPENJPA-1387.
------------------------------------

Resolution: Fixed
Fix Version/s: 2.0.0-M4

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OPENJPA-1387) Unique colums automatically defined as non-nullable

2009-11-16T01:36:41Z

[ https://issues.apache.org/jira/browse/OPENJPA-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pinaki Poddar reassigned OPENJPA-1387:
--------------------------------------

Assignee: Pinaki Poddar (was: Michael Dick)

> Unique colums automatically defined as non-nullable
> ---------------------------------------------------
>
> Key: OPENJPA-1387
> URL: https://issues.apache.org/jira/browse/OPENJPA-1387
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.0.0-M3
> Environment: Error happens in every environment.
> Reporter: Martin Dirichs
> Assignee: Pinaki Poddar
> Attachments: OpenJPA-Trunk_OJ1387.patch
>
>
> Any unique constraint declared with OpenJPA implicitly sets the respective columns to be non-null. This is a problem if OpenJPA's mapping tool is used to create the database schema. Even if something like @Column(nullable=true) is explicitly stated, the columns will always be created by OpenJPA as not null.
> Modifying the database schema manually to make the columns nullable is a possible workaround. It does not seem to cause any problems with either OpenJPA or the databases.
> I would suggest to drop the marking of unique columns as not nullable. This is done by removing the corresponding code lines in org.apache.openjpa.jdbc.schema.Unique (trivial patch appended to this issue). If someone wants a unique column to be not nullable, this can be specified explicitly with @Column(nullable=false) as usual.
> I can only speculate about the reason this strange coupling of unique and nullable had been introduced into OpenJPA. To my knowledge, it is perfectly legal use to have unique contraints on nullable columns. In effect this means that there may be multiple rows with null values, whilst all rows with non-null values have to be unique. ANSI SQL-92 also explicitly mentions nullable unique columns and states that this is a crucial difference between PRIMARY KEY columns and UNIQUE columns: the former are always not nullable, the latter may be nullable.
> This issue also pops up again and again in the user discussions, without (to my knowledge) a single authorative answer to why this behaviour is as it is in OpenJPA. Two examples:
> My question, which remained unanswered:
> http://n2.nabble.com/Unique-colums-automatically-made-NOT-NULL-td2827809.html
> Another users question, about a month later:
> http://n2.nabble.com/Nullable-unique-constraints-td3161182.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OPENJPA-1387) Unique colums automatically defined as non-nullable

2009-11-13T08:25:39Z

[ https://issues.apache.org/jira/browse/OPENJPA-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dick reassigned OPENJPA-1387:
-------------------------------------

Assignee: Michael Dick

> Unique colums automatically defined as non-nullable
> ---------------------------------------------------
>
> Key: OPENJPA-1387
> URL: https://issues.apache.org/jira/browse/OPENJPA-1387
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.0.0-M3
> Environment: Error happens in every environment.
> Reporter: Martin Dirichs
> Assignee: Michael Dick
> Attachments: OpenJPA-Trunk_OJ1387.patch
>
>
> Any unique constraint declared with OpenJPA implicitly sets the respective columns to be non-null. This is a problem if OpenJPA's mapping tool is used to create the database schema. Even if something like @Column(nullable=true) is explicitly stated, the columns will always be created by OpenJPA as not null.
> Modifying the database schema manually to make the columns nullable is a possible workaround. It does not seem to cause any problems with either OpenJPA or the databases.
> I would suggest to drop the marking of unique columns as not nullable. This is done by removing the corresponding code lines in org.apache.openjpa.jdbc.schema.Unique (trivial patch appended to this issue). If someone wants a unique column to be not nullable, this can be specified explicitly with @Column(nullable=false) as usual.
> I can only speculate about the reason this strange coupling of unique and nullable had been introduced into OpenJPA. To my knowledge, it is perfectly legal use to have unique contraints on nullable columns. In effect this means that there may be multiple rows with null values, whilst all rows with non-null values have to be unique. ANSI SQL-92 also explicitly mentions nullable unique columns and states that this is a crucial difference between PRIMARY KEY columns and UNIQUE columns: the former are always not nullable, the latter may be nullable.
> This issue also pops up again and again in the user discussions, without (to my knowledge) a single authorative answer to why this behaviour is as it is in OpenJPA. Two examples:
> My question, which remained unanswered:
> http://n2.nabble.com/Unique-colums-automatically-made-NOT-NULL-td2827809.html
> Another users question, about a month later:
> http://n2.nabble.com/Nullable-unique-constraints-td3161182.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.