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 Thu, 31 Dec 2009 20:53:29 GMT

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


Mime
View raw message