db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4491) The network client changes UDTs into Strings and returns their type as LONGVARBINARY.
Date Sun, 10 Jan 2010 17:27:54 GMT

     [ 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,,,,,, and
against a server.

o A 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 client against a server and vice versa.

Note that the JCC driver was tested because that is the driver used when the client jar is

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:,,,,,,,,,,,,,,
>            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.

View raw message