Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 1 Nov 2013 10:33:19 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12595258.1340194205691.6213.1383301999127@arcas>
In-Reply-To: <JIRA.12595258.1340194205691@arcas>
References: <JIRA.12595258.1340194205691@arcas>
Subject: [jira] [Commented] (DERBY-5823) Multi-row insert fails on table
 without generated keys with RETURN_GENERATED_KEYS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811157#comment-13811157 ] 

ASF subversion and git services commented on DERBY-5823:
--------------------------------------------------------

Commit 1537888 from [~knutanders] in branch 'code/trunk'
[ https://svn.apache.org/r1537888 ]

DERBY-5823: Multi-row insert fails on table without generated keys with RETURN_GENERATED_KEYS

The fix contains two parts:

1. Don't collect generated keys if the statement does not actually
   generate key values. (This is the fix for the reported problem.)

2. Cache the array of generated key columns between executions. In the
   existing code, the array of key columns was created only on the
   first execution. Since it wasn't cached, it was null on all
   subsequent executions. When it is null, all columns are collected
   into the temporary row holder, which wastes space. Now, only the
   key columns are collected, also on re-execution.

The test case was contributed by Kristian Waagan.

> 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.1.1
>            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
(v6.1#6144)