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] Commented: (DERBY-4491) The network client changes UDTs into Strings and returns their type as LONGVARBINARY.
Date Wed, 14 Apr 2010 16:56:48 GMT

    [ 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

        

Mime
View raw message