[
https://issues.apache.org/jira/browse/DERBY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667920#action_12667920
]
Kathey Marsden commented on DERBY-4031:
---------------------------------------
Thanks Knut for the input. Do you think we should throw an exception for the
emptyArray and nullParam cases too, since we currently treat those as
NO_KEYS_GENERATED or do you think we should do something else for those cases?
> 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.
