[
https://issues.apache.org/jira/browse/DERBY-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4491:
---------------------------------
Attachment: derby-4491-01-ad-networkTransport.diff
Attaching derby-4491-01-ad-networkTransport .diff. This patch adds regression
and compatibility tests to the previous patch and fixes a bug disclosed by
those tests. I believe that this patch is commit-worthy.
The compatibility tests verify that the new behavior only appears if both
client and server are Derby code at level 10.6 or higher. In all other cases,
the old behavior prevails. I ran the compatibility tests with the following
combinations:
o VMs used were 1.4, Java 5, and Java 6 for both clients and servers.
o Clients ran at levels 10.0.2.1, 10.1.3.1, 10.2.2.1, 10.3.3.0, 10.4.2.1,
10.5.3.0, and 10.6.0.0 against a 10.6.0.0 server.
o A 10.6.0.0 client ran against servers at all of the levels listed above.
o As a sanity check that the compatibility tests still run cleanly against old
releases, I also ran a 10.3.3.0 client against a 10.5.3.0 server and vice versa.
Note that the JCC driver was tested because that is the driver used when the
client jar is 10.0.2.1.
One other note: with the current state of the trunk (without this patch), we
get a protocol error when trying to use the trunk's NetworkServerControl to
ping a server at various lower rev levels. I did not systematically map out the
combinations that give rise to protocol errors. I don't consider this to be a
serious defect and it may already be understood by our network experts.
However, I had to disable the ping logic in the compatibility tests. With this
patch, the tests simply wait for a while to give the server a chance to come
up. If someone wants to fix this defect, then they can re-enable the ping while
they are in there.
Touches the following files in addition to the files touched by the previous
patch:
M
java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilityCombinations.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilitySuite.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/JDBCDriverTest.java
M
java/testing/org/apache/derbyTesting/functionTests/util/DerbyJUnitTest.java
> The network client changes UDTs into Strings and returns their type as
> LONGVARBINARY.
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4491
> URL: https://issues.apache.org/jira/browse/DERBY-4491
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
> 10.5.1.1, 10.5.2.0, 10.5.3.0
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-4491-01-ab-networkTransport.diff,
> derby-4491-01-ad-networkTransport.diff
>
>
> This is a pre-existing bug which seems to have been with Derby since the
> beginning. Some of the columns in the system tables (e.g.,
> SYS.SYSALIASES.ALIASINFO) contain objects. If you select these columns:
> 1) In the embedded client you will get the correct results. You will get the
> objects in these columns. In addition, the ResultSetMetaData for these
> columns will correctly report that the columns have type JAVA_OBJECT and will
> give a reasonable type name (the class name for the object in the column).
> 2) However, in the network client, you will get the wrong results.
> ResultSet.getObject() will return Strings rather than the original objects.
> In addition, the ResultSetMetaData for these columns will incorrectly report
> that their type is LONGVARBINARY.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
