[
https://issues.apache.org/jira/browse/DERBY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667730#action_12667730
]
Mamta A. Satoor commented on DERBY-4031:
----------------------------------------
I have no standards to backup my input here but I think we should always return
a ResultSet whose metadata matches the signature of identity_Val_local(). In
other words, whether we are dealing with
1)Statement.getGeneratedKeys() with Statement.RETURN_GENERATED_KEYS but the
statement does not generate any keys
2)Statement.getGeneratedKeys() with Statement.NO_GENERATED_KEYS
we should return a consistent ResultSet object where the metadata stays the
same.
> 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.
