[
https://issues.apache.org/jira/browse/DERBY-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856959#action_12856959
]
Rick Hillegas commented on DERBY-4491:
--------------------------------------
I have re-run the compatibility tests using combinations of clients and servers
at trunk and 10.5.3.0 levels. This should stress the change made by Kristian
since a 10.5.3.0 server supports data caching but not UDTs. The compatibility
tests passed cleanly in this combination.
I believe that the tests previously passed because the only check for
serverSupportsUDT() occurs in NetStatementReply.parseSQLUDTGRP():
if ( !(jdbcType == Types.JAVA_OBJECT) ||
!netAgent_.netConnection_.serverSupportsUDTs() )
This condition would have been satisified even if serverSupportsUDTs() returned
the wrong value because if the server really wasn't at level 10.6, then
jdbcType would be Types.LONGVARBINARY.
I suppose this means that we could remove the serverSupportsUDTs() method.
However, I recommend keeping this redundant sanity check because:
a) it causes no problems
b) it flags the point in a code where we need to be UDT-aware
> 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
> Fix For: 10.6.0.0
>
> Attachments: derby-4491-01-ab-networkTransport.diff,
> derby-4491-01-ad-networkTransport.diff, derby-4491-02-aa-supportsUDTs.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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
