You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "David Blevins (JIRA)" <ji...@apache.org> on 2009/01/26 08:12:59 UTC
[jira] Created: (OPENJPA-872) Compound custom id in bidirectional
many-to-one
Compound custom id in bidirectional many-to-one
-----------------------------------------------
Key: OPENJPA-872
URL: https://issues.apache.org/jira/browse/OPENJPA-872
Project: OpenJPA
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: David Blevins
Priority: Blocker
It seems that the order of parameters filled into the SQLBuffer are getting mixed. Seeing this with a bidirectional many-to-one where the owning side uses a compound primary key resulting in a compound foreign key. When the owning side's collection is loaded the sql is correctly generated with the foreign keys in the where clause but the values are not passed in the correct order. There is clearly great care taken in regards to order when the sql string SQLBuffer is getting filled in, but there seems to be a second pass where the parameter values are collected and the order in this case *appears* to be alphabetical. I.e. the two values in the compound key are "id" and "brandname", if "brandname" is renamed to "zbrandname" the test will consistently pass.
Caused by: <openjpa-1.2.0-r422266:683325 nonfatal store error> org.apache.openjpa.util.StoreException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
at org.apache.openjpa.jdbc.sql.HSQLDictionary.newStoreException(HSQLDictionary.java:292)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:632)
at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2920)
at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2998)
at org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2241)
at org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:777)
at org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:739)
at org.apache.openjpa.enhance.RedefinitionHelper$1.invoke(RedefinitionHelper.java:230)
at $Proxy20.size(Unknown Source)
at org.superbiz.customid.TestBean.tx2(TestBean.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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:122)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:211)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:169)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:286)
... 25 more
Caused by: java.sql.SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.setParameter(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.setString(Unknown Source)
at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setString(LoggingConnectionDecorator.java:990)
at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
at org.apache.openjpa.jdbc.sql.DBDictionary.setString(DBDictionary.java:1097)
at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1298)
at org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:630)
at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:529)
at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:485)
at org.apache.openjpa.jdbc.sql.SelectImpl.prepareStatement(SelectImpl.java:463)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:379)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
at org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:599)
at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:819)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:626)
... 47 more
Here's a snapshot of the SelectImp instance just after it is built:
• this = {org.apache.openjpa.jdbc.sql.SelectImpl@8556}"SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
• mapping = {org.apache.openjpa.jdbc.meta.ClassMapping@8381}"org.superbiz.customid.Invoice"
• toCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
• [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
• [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
• fromCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
• [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
• [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
• oid = {org.apache.openjpa.util.ObjectId@8383}"org.superbiz.customid.Invoice-org.superbiz.customid.InvoiceKey@c412bd2"
• store = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager@8373}
• pj = null
• buf = null
• parmList = {java.util.ArrayList@8720} size = 0
• collectParmValueOnly = true
• pks = {java.lang.Object[2]@8790}
• [0] = {java.lang.String@8413}"Red"
• [1] = {java.lang.Integer@8429}"1"
• toCols.length = 2
Note the primary key values are in the incorrect order for the way the sql statement was built. Later when setParameters is called:
• this = {org.apache.openjpa.jdbc.sql.SQLBuffer@7747}
• ps = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement@7752}"prepstmnt 7374346 SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
• cacheParams = {java.util.ArrayList@7753} size = 2
• [0] = {java.lang.String@7648}"Red"
• [1] = {java.lang.Integer@7652}"1"
• _params = {java.util.ArrayList@7754} size = 2
• [0] = {java.lang.Integer@7652}"1"
• [1] = {java.lang.String@7648}"Red"
The interesting thing is that the value of _params is correct and matches the sql. For some reason there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-872) Compound custom id in bidirectional
many-to-one
Posted by "Jeremy Bauer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Bauer resolved OPENJPA-872.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.3.0
1.2.1
Assignee: Jeremy Bauer
David,
Thanks for the excellent test case and failure documentation. As Kevin suspected, this problem is/was related to QuerySQLCache. This problem was fixed in OPENJPA-838, revision 728758 of 1.2.x (1.2.1-SNAPSHOT). Either changing your pom to include the 1.2.1-SNAPSHOT or adding this property:
<property name="openjpa.jdbc.QuerySQLCache" value="false"/>
to your persistence.xml will correct the problem.
> Compound custom id in bidirectional many-to-one
> -----------------------------------------------
>
> Key: OPENJPA-872
> URL: https://issues.apache.org/jira/browse/OPENJPA-872
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: David Blevins
> Assignee: Jeremy Bauer
> Priority: Blocker
> Fix For: 1.2.1, 1.3.0, 2.0.0
>
> Attachments: jpa-customid.tar.gz
>
>
> It seems that the order of parameters filled into the SQLBuffer are getting mixed. Seeing this with a bidirectional many-to-one where the owning side uses a compound primary key resulting in a compound foreign key. When the owning side's collection is loaded the sql is correctly generated with the foreign keys in the where clause but the values are not passed in the correct order. There is clearly great care taken in regards to order when the sql string SQLBuffer is getting filled in, but there seems to be a second pass where the parameter values are collected and the order in this case *appears* to be alphabetical. I.e. the two values in the compound key are "id" and "brandname", if "brandname" is renamed to "zbrandname" the test will consistently pass.
> Caused by: <openjpa-1.2.0-r422266:683325 nonfatal store error> org.apache.openjpa.util.StoreException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
> at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
> at org.apache.openjpa.jdbc.sql.HSQLDictionary.newStoreException(HSQLDictionary.java:292)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:632)
> at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
> at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
> at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2920)
> at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2998)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2241)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:777)
> at org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:739)
> at org.apache.openjpa.enhance.RedefinitionHelper$1.invoke(RedefinitionHelper.java:230)
> at $Proxy20.size(Unknown Source)
> at org.superbiz.customid.TestBean.tx2(TestBean.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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:122)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:211)
> at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:169)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:286)
> ... 25 more
> Caused by: java.sql.SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setParameter(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setString(Unknown Source)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setString(LoggingConnectionDecorator.java:990)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setString(DBDictionary.java:1097)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1298)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:630)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:529)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:485)
> at org.apache.openjpa.jdbc.sql.SelectImpl.prepareStatement(SelectImpl.java:463)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:379)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
> at org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
> at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:599)
> at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:819)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:626)
> ... 47 more
> Here's a snapshot of the SelectImp instance just after it is built:
> • this = {org.apache.openjpa.jdbc.sql.SelectImpl@8556}"SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • mapping = {org.apache.openjpa.jdbc.meta.ClassMapping@8381}"org.superbiz.customid.Invoice"
> • toCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • fromCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • oid = {org.apache.openjpa.util.ObjectId@8383}"org.superbiz.customid.Invoice-org.superbiz.customid.InvoiceKey@c412bd2"
> • store = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager@8373}
> • pj = null
> • buf = null
> • parmList = {java.util.ArrayList@8720} size = 0
> • collectParmValueOnly = true
> • pks = {java.lang.Object[2]@8790}
> • [0] = {java.lang.String@8413}"Red"
> • [1] = {java.lang.Integer@8429}"1"
> • toCols.length = 2
> Note the primary key values are in the incorrect order for the way the sql statement was built. Later when setParameters is called:
> • this = {org.apache.openjpa.jdbc.sql.SQLBuffer@7747}
> • ps = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement@7752}"prepstmnt 7374346 SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • cacheParams = {java.util.ArrayList@7753} size = 2
> • [0] = {java.lang.String@7648}"Red"
> • [1] = {java.lang.Integer@7652}"1"
> • _params = {java.util.ArrayList@7754} size = 2
> • [0] = {java.lang.Integer@7652}"1"
> • [1] = {java.lang.String@7648}"Red"
> The interesting thing is that the value of _params is correct and matches the sql. For some reason there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-872) Compound custom id in bidirectional
many-to-one
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670164#action_12670164 ]
Pinaki Poddar commented on OPENJPA-872:
---------------------------------------
1. With new Prepared Query Cache, this example works both for find() as well as query.
2. Prepared Query Cache is available since SVN revision 740208.
3. OPENJPA-703 is tracking the development of this new Prepared Query Cache.
4. This cache is active by default.
It can be switched off as above
<property name="openjpa.jdbc.QuerySQLCache" value="false"/>
> Compound custom id in bidirectional many-to-one
> -----------------------------------------------
>
> Key: OPENJPA-872
> URL: https://issues.apache.org/jira/browse/OPENJPA-872
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: David Blevins
> Assignee: Jeremy Bauer
> Priority: Blocker
> Fix For: 1.2.1, 1.3.0, 2.0.0
>
> Attachments: jpa-customid.tar.gz
>
>
> It seems that the order of parameters filled into the SQLBuffer are getting mixed. Seeing this with a bidirectional many-to-one where the owning side uses a compound primary key resulting in a compound foreign key. When the owning side's collection is loaded the sql is correctly generated with the foreign keys in the where clause but the values are not passed in the correct order. There is clearly great care taken in regards to order when the sql string SQLBuffer is getting filled in, but there seems to be a second pass where the parameter values are collected and the order in this case *appears* to be alphabetical. I.e. the two values in the compound key are "id" and "brandname", if "brandname" is renamed to "zbrandname" the test will consistently pass.
> Caused by: <openjpa-1.2.0-r422266:683325 nonfatal store error> org.apache.openjpa.util.StoreException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
> at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
> at org.apache.openjpa.jdbc.sql.HSQLDictionary.newStoreException(HSQLDictionary.java:292)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:632)
> at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
> at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
> at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2920)
> at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2998)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2241)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:777)
> at org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:739)
> at org.apache.openjpa.enhance.RedefinitionHelper$1.invoke(RedefinitionHelper.java:230)
> at $Proxy20.size(Unknown Source)
> at org.superbiz.customid.TestBean.tx2(TestBean.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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:122)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:211)
> at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:169)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:286)
> ... 25 more
> Caused by: java.sql.SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setParameter(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setString(Unknown Source)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setString(LoggingConnectionDecorator.java:990)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setString(DBDictionary.java:1097)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1298)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:630)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:529)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:485)
> at org.apache.openjpa.jdbc.sql.SelectImpl.prepareStatement(SelectImpl.java:463)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:379)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
> at org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
> at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:599)
> at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:819)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:626)
> ... 47 more
> Here's a snapshot of the SelectImp instance just after it is built:
> • this = {org.apache.openjpa.jdbc.sql.SelectImpl@8556}"SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • mapping = {org.apache.openjpa.jdbc.meta.ClassMapping@8381}"org.superbiz.customid.Invoice"
> • toCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • fromCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • oid = {org.apache.openjpa.util.ObjectId@8383}"org.superbiz.customid.Invoice-org.superbiz.customid.InvoiceKey@c412bd2"
> • store = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager@8373}
> • pj = null
> • buf = null
> • parmList = {java.util.ArrayList@8720} size = 0
> • collectParmValueOnly = true
> • pks = {java.lang.Object[2]@8790}
> • [0] = {java.lang.String@8413}"Red"
> • [1] = {java.lang.Integer@8429}"1"
> • toCols.length = 2
> Note the primary key values are in the incorrect order for the way the sql statement was built. Later when setParameters is called:
> • this = {org.apache.openjpa.jdbc.sql.SQLBuffer@7747}
> • ps = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement@7752}"prepstmnt 7374346 SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • cacheParams = {java.util.ArrayList@7753} size = 2
> • [0] = {java.lang.String@7648}"Red"
> • [1] = {java.lang.Integer@7652}"1"
> • _params = {java.util.ArrayList@7754} size = 2
> • [0] = {java.lang.Integer@7652}"1"
> • [1] = {java.lang.String@7648}"Red"
> The interesting thing is that the value of _params is correct and matches the sql. For some reason there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-872) Compound custom id in bidirectional
many-to-one
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins updated OPENJPA-872:
----------------------------------
Attachment: jpa-customid.tar.gz
Attached is a test case for representing the issue. It leverages openejb for simplicity in the setup department. Should be no problem to rework it to standalone jpa.
> Compound custom id in bidirectional many-to-one
> -----------------------------------------------
>
> Key: OPENJPA-872
> URL: https://issues.apache.org/jira/browse/OPENJPA-872
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: David Blevins
> Priority: Blocker
> Attachments: jpa-customid.tar.gz
>
>
> It seems that the order of parameters filled into the SQLBuffer are getting mixed. Seeing this with a bidirectional many-to-one where the owning side uses a compound primary key resulting in a compound foreign key. When the owning side's collection is loaded the sql is correctly generated with the foreign keys in the where clause but the values are not passed in the correct order. There is clearly great care taken in regards to order when the sql string SQLBuffer is getting filled in, but there seems to be a second pass where the parameter values are collected and the order in this case *appears* to be alphabetical. I.e. the two values in the compound key are "id" and "brandname", if "brandname" is renamed to "zbrandname" the test will consistently pass.
> Caused by: <openjpa-1.2.0-r422266:683325 nonfatal store error> org.apache.openjpa.util.StoreException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
> at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
> at org.apache.openjpa.jdbc.sql.HSQLDictionary.newStoreException(HSQLDictionary.java:292)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
> at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:632)
> at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
> at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
> at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2920)
> at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2998)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2241)
> at org.apache.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:777)
> at org.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:739)
> at org.apache.openjpa.enhance.RedefinitionHelper$1.invoke(RedefinitionHelper.java:230)
> at $Proxy20.size(Unknown Source)
> at org.superbiz.customid.TestBean.tx2(TestBean.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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:122)
> at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:211)
> at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:169)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
> at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:286)
> ... 25 more
> Caused by: java.sql.SQLException: Wrong data type: java.lang.NumberFormatException: For input string: "Red"
> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setParameter(Unknown Source)
> at org.hsqldb.jdbc.jdbcPreparedStatement.setString(Unknown Source)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.setString(LoggingConnectionDecorator.java:990)
> at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:309)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setString(DBDictionary.java:1097)
> at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1298)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:630)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:529)
> at org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:485)
> at org.apache.openjpa.jdbc.sql.SelectImpl.prepareStatement(SelectImpl.java:463)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:379)
> at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
> at org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
> at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
> at org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.load(StoreCollectionFieldStrategy.java:599)
> at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:819)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:626)
> ... 47 more
> Here's a snapshot of the SelectImp instance just after it is built:
> • this = {org.apache.openjpa.jdbc.sql.SelectImpl@8556}"SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • mapping = {org.apache.openjpa.jdbc.meta.ClassMapping@8381}"org.superbiz.customid.Invoice"
> • toCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • fromCols = {org.apache.openjpa.jdbc.schema.Column[2]@8382}
> • [0] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8409}"BRANDNAME"
> • [1] = {org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn@8425}"ID"
> • oid = {org.apache.openjpa.util.ObjectId@8383}"org.superbiz.customid.Invoice-org.superbiz.customid.InvoiceKey@c412bd2"
> • store = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager@8373}
> • pj = null
> • buf = null
> • parmList = {java.util.ArrayList@8720} size = 0
> • collectParmValueOnly = true
> • pks = {java.lang.Object[2]@8790}
> • [0] = {java.lang.String@8413}"Red"
> • [1] = {java.lang.Integer@8429}"1"
> • toCols.length = 2
> Note the primary key values are in the incorrect order for the way the sql statement was built. Later when setParameters is called:
> • this = {org.apache.openjpa.jdbc.sql.SQLBuffer@7747}
> • ps = {org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement@7752}"prepstmnt 7374346 SELECT t0.ID, t0.QUANTITY FROM LINEITEM t0 WHERE t0.FK_FOR_ID = ? AND t0.FK_FOR_BRANDNAME = ?"
> • cacheParams = {java.util.ArrayList@7753} size = 2
> • [0] = {java.lang.String@7648}"Red"
> • [1] = {java.lang.Integer@7652}"1"
> • _params = {java.util.ArrayList@7754} size = 2
> • [0] = {java.lang.Integer@7652}"1"
> • [1] = {java.lang.String@7648}"Red"
> The interesting thing is that the value of _params is correct and matches the sql. For some reason there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.