[jira] Commented: (DERBY-4491) The network client changes UDTs into Strings and returns their type as LONGVARBINARY.

["Rick Hillegas (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795671#action_12795671 ] 

Rick Hillegas commented on DERBY-4491:
--------------------------------------

Here are some thoughts about how to address this issue.

DRDA does support user defined types and our existing protocol flows maintain a placeholder for UDT information. Right now we plug a null into that placeholder. For more detail on this support, see the February 2007 version of the DRDA spec, Volume 1 (Data Definition and Exchange), section 5.6.4.10 (SQL Descriptor User-Defined Type Group Description, aka SQLUDTGRP).

The DRDA support for user defined types, however, is not rich enough to describe the Java user defined types defined by part 13 of the ANSI/ISO SQL Standard. These are the user defined types identified by the JDBC type code java.sql.Types.JAVA_OBJECT. DRDA support only covers SQL distinct, struct, and ref types, that is, those which map to the STRUCT, DISTINCT, and REF constants in java.sql.Types. There is no corresponding DRDA constant mapping to java.sql.Types.JAVA_OBJECT. In addition, the DRDA protocol does not convey the Java class name needed to fulfill the JDBC contract for ResultSetMetaData.getColumnClassName() and ParameterMetaData.getParameterClassName().

Therefore, in order to fulfill the JDBC contract, we will have to extend the DRDA protocol. I propose the following:

1) For compatibility reasons, we will maintain the old, incorrect behavior if either the client or the server is NOT Derby code at level 10.6 or higher.

2) However, if the client and server are both Derby code at version 10.6 or higher, then the user will see the embedded behavior. Internally, we will implement this with Derby-specific extensions to DRDA. This affects the following methods:

ResultSet.getObject() - Will return the UDT object rather than the result of calling toString() on it.

PreparedStatement.setObject() - Will accept UDTs if the parameter is typed as JAVA_OBJECT. The object being set must be an instance of the Java class which was bound to the UDT by the CREATE TYPE statement.

ResultSetMetaData.getColumnType() and ParameterMetaData.getParameterType() - Will return JAVA_OBJECT rather than LONGVARBINARY.

ResultSetMetaData.getColumnTypeName() and ParameterMetaData.getParameterTypeName() - Will return the fully qualified name of the UDT rather than LONG VARCHAR FOR BIT DATA. However, for our legacy user defined types (the ones stored in the system tables), we will continue to follow the embedded practice of returning the class name without any schema qualifier. So, for a column of type Price, we will return what is required by the JDBC spec

  "APP"."PRICE"

but for SELECT ALIASINFO FROM SYS.SYSALIASES, we will return

  org.apache.derby.catalog.AliasInfo

This behavior for the system columns seems to fall short of the JDBC contract. However, these are special types and I am content to leave them alone. If we are not happy about this approach for the system columns, then we should open a new JIRA and come up with a better common behavior for both embedded and network usage.


ResultSetMetaData.getColumnClassName() and ParameterMetaData.getParameterClassName() - Will return the name of the class bound to the UDT when it was defined.

ResultSetMetaData.getColumnPrecision() and ParameterMetaData.getPrecision() - Will return 0 as in the embedded case.

ResultSetMetaData.getColumnScale() and ParameterMetaData.getScale()- Will return 0 as in the embedded case.

ResultSetMetaData.getColumnDisplaySize() - Will return 15 as in the embedded case. This is Derby's default column display size and seems arbitrary to me. However, I find it hard to argue for some other number. If we decide that some other number is better, then we should open a new JIRA and use the same number for both embedded and network situations.


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