[
https://issues.apache.org/jira/browse/DERBY-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton updated DERBY-6849:
-----------------------------------
Attachment: generated-keys-with-tests.diff
I took the 'generated-keys.diff' that Knut Anders attached to DERBY-3609.
I also took the repro script from this job, and the repo script from
DERBY-3609, and I edited them into AutoGenJDBC30Test as new
test cases.
Then I ran the entire test suite.
The results were fairly encouraging:
- with Knut Anders's patch applied both repro scripts pass in the
embedded configuration
- the vast majority of the existing tests pass
However, there are problems to be resolved:
- although the new repro scripts (from DERBY-3609 and DERBY-6849)
pass in the embedded configuration, they fail in the client-server
configuration.
- A number of other existing test cases, particularly in AutoGenJDBC30Test,
fail with the patch applied. This is because of the explicit change of
behavior due to the patch
- The change to InsertResultSet (disabling the automatic close of
the autogeneratedKeys result set when the InsertResultSet is closed)
is clearly wrong, and causes several test failures of its own.
- additional test cases are clearly needed to explore the full behavior
of Knut Anders's patch in the multi-row-insert case (and the update case?)
- As Knut Anders noted in DERBY-3609, whatever we do here, we'll
need to document the new behavior.
Regardless, I think this, overall, is good progress, so attaching the
patch that I was working with.
> Statement.RETURN_GENERATED_KEYS returns a 1 row result set even if there are
> no auto-generated fields
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-6849
> URL: https://issues.apache.org/jira/browse/DERBY-6849
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.9.1.0
> Reporter: John Hendrikx
> Attachments: DERBY6849Repro.java, firstExperimentNotForCommit.diff,
> generated-keys-with-tests.diff
>
>
> If:
> 1) A JDBC INSERT statement is executed, with Statement.RETURN_GENERATED_KEYS
> enabled, and
> 2) A call is then made to Statement.getGeneratedKeys, and
> 3) The table which was inserted into has *NO* generated columns,
> then getGeneratedKeys() returns a ResultSet object with a single row in it.
> This behavior seems incorrect; it seems that the correct behavior
> would be to return a ResultSet object which has *NO* rows in it, so
> that ResultSet.next() returns FALSE the first time it is called.
>
> I have a very simple table:
> {noformat}
> CREATE TABLE images (
> url varchar(1000) NOT NULL,
> image blob NOT NULL,
>
> CONSTRAINT images_url PRIMARY KEY (url)
> );
> {noformat}
> No auto-generated fields. However when I do an insert, JDBC tells me there
> are auto-generated keys (rs.next() does not return false and a LONG value is
> returned):
> {noformat}
> try(PreparedStatement statement = connection.prepareStatement(sql,
> Statement.RETURN_GENERATED_KEYS)) {
> setParameters(parameterValues, statement);
> statement.execute();
> try(ResultSet rs = statement.getGeneratedKeys()) {
> if(rs.next()) {
> return rs.getObject(1);
> }
> return null;
> }
> }
> catch(SQLException e) {
> throw new DatabaseException(this, sql + ": " + parameters, e);
> }
> {noformat}
> This sounds like a bug to me. For comparison, PostgreSQL does not have the
> same behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
