db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5823) Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS
Date Wed, 30 Oct 2013 15:29:34 GMT

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

Knut Anders Hatlen updated DERBY-5823:

    Attachment: derby-5823-2a.diff

Attaching derby-5823-2a.diff which tackles problem 1 and 2 mentioned above.

It skips adding rows to the temporary row holder if there are no columns to add. This means
the row holder will never overflow to disk if there are no generated keys, so there will be
no attempt to create a heap conglomerate with zero-length rows, and the "Conglomerate could
not be created" error is avoided.

It also keeps the set of key columns between executions so that we avoid the overhead of collecting
all columns for all inserted rows on re-execution. In addition to avoiding overhead, this
also ensures that the internal result set that holds the generated keys (InsertResultSet.autoGeneratedKeysResultSet)
has the correct shape. Although the shape of this ResultSet doesn't matter right now (getGeneratedKeys()
only cares whether it's non-null), this might change in DERBY-3609, so this should also get

And while I was at it, I just couldn't resist the temptation to replace a for loop with a
call to Arrays.fill() in InsertResultSet.generatedColumnPositionsArray()...

The regression test case contributed by Kristian passed with the fix. So did all the existing
regression tests in derbyall and suites.All.

> 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:,,,
>            Reporter: Kristian Waagan
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_triage10_10
>         Attachments: derby-5823-1a-regression_test.diff, derby-5823-2a.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 was sent by Atlassian JIRA

View raw message