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] Commented: (DERBY-4031) If NO_GENERATED_KEYS is specified, Statement.getGeneratedKeys should return an empty ResultSet, not null
Date Wed, 28 Jan 2009 08:54:59 GMT

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

Knut Anders Hatlen commented on DERBY-4031:
-------------------------------------------

What I would have expected was that at least nullParam would throw an exception, since the
javadoc says that the parameter should be an array, and null is not an array.

The returned ResultSet normally has as many columns as there are elements in the array. So
if we don't throw an exception for emptyArray, the consistent way to handle it would be to
return a ResultSet with 0 columns and the same number of rows as the number of generated keys.
I don't see how this could be useful, though, so it might be better to reject it with an error
like "Auto-generated keys must have at least one column" or something.

> If NO_GENERATED_KEYS is specified, Statement.getGeneratedKeys should return an empty
ResultSet, not null 
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4031
>                 URL: https://issues.apache.org/jira/browse/DERBY-4031
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.0.0
>            Reporter: Kathey Marsden
>             Fix For: 10.5.0.0
>
>
> Currently Derby returns null from Statement.getGeneratedKeys() if  the statement is prepared
or executed with Statement.NO_GENERATED_KEYS. The javadoc says:
> If this Statement object did not generate any keys, an empty ResultSet object is returned.
> so we should return an empty ResultSet for this case.  It is not entirely clear what
the structure of the ResultSet and ResultSetMetaData should be.  I tend to think the following:
> getConcurrency() - inherit from the parent statement
> getStatement() - null
> ResultSetMetaData
> getColumnCount - 0
> an alternative would be to have the ResultSetMetaData match the signature of Identity_Val_local()
but I think to return 0 columns makes more sense.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message