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