[
https://issues.apache.org/jira/browse/DERBY-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4015:
----------------------------------
Attachment: Derby4015.java
I created a small java program from Brandon's tests so we could remove the
eclipse dependency since not everyone uses eclipse. To run embedded run:
java Derby4015.
For embedded on trunk the result is:
emptyArray test (new String[] { })
Null Result
fakeColumn test: (new String[] { "value" })
Caught exception SQLSTATE=X0X0F message=Table 'INSERTTEST' does not have an
auto-generated column named 'value'.
nullArray test: (new String[] { null })
Caught exception SQLSTATE=X0X0F message=Table 'INSERTTEST' does not have an
auto-generated column named 'null'.
nullParamTest (null)
Null Result
To run for client, start network server and run
java Derby4015 client
For client the results are:
emptyArray test (new String[] { })
Null Result
fakeColumn test: (new String[] { "value" })
2
nullArray test: (new String[] { null })
3
nullParam test (null)
Null Result
One thing I notice is that for the fakeColumn and nullArray cases the matrix is
not correct. For the fakeColumn and nullArray cases we do not return an empty
result for client; we return the value of the identity column. This is
documented as the current client behavior:
http://db.apache.org/derby/docs/10.4/ref/crefjavstateautogen.html
"With the client driver, the one element column name is ignored currently and
the value returned corresponds to the identity column. To ensure compatibility
with future changes an application should ensure the column described is the
identity column. If the column name corresponds to another column or a
non-existent column then future changes may result in a value for a different
column being returned or an exception being thrown."
The client currently has no way to know which is the generated column so can't
check.
A couple things in the javadoc struck me.
First is this note:
Note:If the columns which represent the auto-generated keys were not
specified, the JDBC driver implementation will determine the columns which best
represent the auto-generated keys.
Does this mean that for the emptyArray and nullParam cases we should return the
generated keys?
Secondly for SQLException it says
SQLException - if a database access error occurs or this method is called
on a closed Statement
It seems to limit SQLExceptions to these cases so it is not clear what should
be done if the column names specified do not match the identity columns.
It would be good to get spec clarification on how these cases should behave.
> Regression in Statement.getGeneratedKeys()
> ------------------------------------------
>
> Key: DERBY-4015
> URL: https://issues.apache.org/jira/browse/DERBY-4015
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.3.3.0
> Environment: I am currently running on Mac 10.5 with Java 5. However,
> it has also been observed on other platforms in our automated build such as
> SUSE Linux and Windows with Java 5.
> Reporter: Brandon Smith
> Priority: Critical
> Attachments: Behavior-Matrix.jpg, derby-10.3.2.1-tests.zip,
> derby-10.3.3.0-tests.zip, Derby4015.java
>
>
> The application of both DERBY-2653 and DERBY-3426 in the 10.3.3.0 seems to
> have created a regression in how the network JDBC client implementation of
> PreparedStatement.getGeneratedKeys() behaves as compared to 10.3.2.1. Note
> that there wasn't a change in behavior between versions for the embedded
> implementation. However, in general there are behavior discrepancies between
> the network and client implementations for this method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
