You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2012/06/20 14:11:42 UTC
[jira] [Created] (DERBY-5823) Multi-row insert fails on table
without generated keys with RETURN_GENERATED_KEYS
Kristian Waagan created DERBY-5823:
--------------------------------------
Summary: Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
Key: DERBY-5823
URL: https://issues.apache.org/jira/browse/DERBY-5823
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.8.2.2, 10.7.1.1, 10.9.1.0, 10.10.0.0
Reporter: Kristian Waagan
Priority: Minor
Exeuting an insert that results in multiple rows being inserted into a table without any generated keys defined fails if the JDBC statement is configured to return generated keys. Example stack trace:
Caused by: ERROR XSCH4: Conglomerate could not be created.
at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:296)
at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(HeapConglomerateFactory.java:206)
at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(RAMTransaction.java:820)
at org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(TemporaryRowHolderImpl.java:302)
at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1007)
at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:508)
at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
... 30 more
This happens only with multi-row inserts, and only with the embedded driver (the client driver uses IDENTITY_VAL_LOCAL).
The problem is that Derby tries to create a temporary conglomerate with a zero-length row template. A guard against this scenario is probably missing.
FYI, the transition threshold (from in-memory to on-disk) is currently five rows.
I marked versions back to 10.7 as affected, but this bug probably goes back all the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5823) Multi-row insert fails on table
without generated keys with RETURN_GENERATED_KEYS
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-5823:
-----------------------------------
Urgency: Normal
> Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
> ---------------------------------------------------------------------------------
>
> Key: DERBY-5823
> URL: https://issues.apache.org/jira/browse/DERBY-5823
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0, 10.10.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Labels: derby_triage10_10
> Attachments: derby-5823-1a-regression_test.diff
>
>
> Exeuting an insert that results in multiple rows being inserted into a table without any generated keys defined fails if the JDBC statement is configured to return generated keys. Example stack trace:
> Caused by: ERROR XSCH4: Conglomerate could not be created.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
> at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:296)
> at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(HeapConglomerateFactory.java:206)
> at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(RAMTransaction.java:820)
> at org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(TemporaryRowHolderImpl.java:302)
> at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1007)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:508)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
> ... 30 more
> This happens only with multi-row inserts, and only with the embedded driver (the client driver uses IDENTITY_VAL_LOCAL).
> The problem is that Derby tries to create a temporary conglomerate with a zero-length row template. A guard against this scenario is probably missing.
> FYI, the transition threshold (from in-memory to on-disk) is currently five rows.
> I marked versions back to 10.7 as affected, but this bug probably goes back all the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5823) Multi-row insert fails on table
without generated keys with RETURN_GENERATED_KEYS
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5823:
-----------------------------------
Attachment: derby-5823-1a-regression_test.diff
Note that this bug was logged due to the following thread on derby-user: "Conglomerate could not be created"? [1]
Attaching a regression test at patch as 1a.
I haven't verified that Derby does the right thing when it comes to what it returns for getGeneratedKeys, so it may fail also when the problems described by this JIRA has been fixed.
[1] http://mail-archives.apache.org/mod_mbox/db-derby-user/201206.mbox/%3C4FC8B339.8090502%40gmail.com%3E
> Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
> ---------------------------------------------------------------------------------
>
> Key: DERBY-5823
> URL: https://issues.apache.org/jira/browse/DERBY-5823
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0, 10.10.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-5823-1a-regression_test.diff
>
>
> Exeuting an insert that results in multiple rows being inserted into a table without any generated keys defined fails if the JDBC statement is configured to return generated keys. Example stack trace:
> Caused by: ERROR XSCH4: Conglomerate could not be created.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
> at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:296)
> at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(HeapConglomerateFactory.java:206)
> at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(RAMTransaction.java:820)
> at org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(TemporaryRowHolderImpl.java:302)
> at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1007)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:508)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
> ... 30 more
> This happens only with multi-row inserts, and only with the embedded driver (the client driver uses IDENTITY_VAL_LOCAL).
> The problem is that Derby tries to create a temporary conglomerate with a zero-length row template. A guard against this scenario is probably missing.
> FYI, the transition threshold (from in-memory to on-disk) is currently five rows.
> I marked versions back to 10.7 as affected, but this bug probably goes back all the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5823) Multi-row insert fails on table
without generated keys with RETURN_GENERATED_KEYS
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5823:
-----------------------------------
Issue & fix info: Repro attached,Workaround attached
The workaround for this issue is to not specify RETURN_GENERATED_KEYS for inserts that don't generate any keys.
Note however that the Java API documentation specifically states that
"If this Statement object did not generate any keys, an empty ResultSet object is returned.", so Derby is misbehaving.
> Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
> ---------------------------------------------------------------------------------
>
> Key: DERBY-5823
> URL: https://issues.apache.org/jira/browse/DERBY-5823
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0, 10.10.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-5823-1a-regression_test.diff
>
>
> Exeuting an insert that results in multiple rows being inserted into a table without any generated keys defined fails if the JDBC statement is configured to return generated keys. Example stack trace:
> Caused by: ERROR XSCH4: Conglomerate could not be created.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
> at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:296)
> at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(HeapConglomerateFactory.java:206)
> at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(RAMTransaction.java:820)
> at org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(TemporaryRowHolderImpl.java:302)
> at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1007)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:508)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
> ... 30 more
> This happens only with multi-row inserts, and only with the embedded driver (the client driver uses IDENTITY_VAL_LOCAL).
> The problem is that Derby tries to create a temporary conglomerate with a zero-length row template. A guard against this scenario is probably missing.
> FYI, the transition threshold (from in-memory to on-disk) is currently five rows.
> I marked versions back to 10.7 as affected, but this bug probably goes back all the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5823) Multi-row insert fails on table
without generated keys with RETURN_GENERATED_KEYS
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-5823:
-----------------------------------
Labels: derby_triage10_10 (was: )
> Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
> ---------------------------------------------------------------------------------
>
> Key: DERBY-5823
> URL: https://issues.apache.org/jira/browse/DERBY-5823
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0, 10.10.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Labels: derby_triage10_10
> Attachments: derby-5823-1a-regression_test.diff
>
>
> Exeuting an insert that results in multiple rows being inserted into a table without any generated keys defined fails if the JDBC statement is configured to return generated keys. Example stack trace:
> Caused by: ERROR XSCH4: Conglomerate could not be created.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
> at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:296)
> at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(HeapConglomerateFactory.java:206)
> at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(RAMTransaction.java:820)
> at org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(TemporaryRowHolderImpl.java:302)
> at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1007)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:508)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
> ... 30 more
> This happens only with multi-row inserts, and only with the embedded driver (the client driver uses IDENTITY_VAL_LOCAL).
> The problem is that Derby tries to create a temporary conglomerate with a zero-length row template. A guard against this scenario is probably missing.
> FYI, the transition threshold (from in-memory to on-disk) is currently five rows.
> I marked versions back to 10.7 as affected, but this bug probably goes back all the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira