db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6849) Statement.RETURN_GENERATED_KEYS returns a 1 row result set even if there are no auto-generated fields
Date Sat, 26 Nov 2016 17:18:58 GMT

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

Bryan Pendleton commented on DERBY-6849:
----------------------------------------

The client code that hard-wires getGeneratedKeys() to IDENTITY_VAL_LOCAL,
and prevents the DERBY-3609 patch from working in the client-server configuration, 
is this code in o.a.d.client.am.ClientStatement:
{code}
    protected static ClientPreparedStatement
            prepareAutoGeneratedKeysStatement(ClientConnection cc)
            throws SqlException {
        String s = "select IDENTITY_VAL_LOCAL() from SYSIBM.SYSDUMMY1";
        ClientPreparedStatement cps =
                    cc.newPreparedStatement_(s,
                            ResultSet.TYPE_FORWARD_ONLY,
                            ResultSet.CONCUR_READ_ONLY,
                            ResultSet.HOLD_CURSORS_OVER_COMMIT,
                            Statement.NO_GENERATED_KEYS,
                            null, null);
{code}

> 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)

Mime
View raw message