[
https://issues.apache.org/jira/browse/DERBY-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876257#action_12876257
]
Rick Hillegas commented on DERBY-4688:
--------------------------------------
Hi Kristian,
For the record, we do supply Derby-specific Externalizable logic for these
objects. In fact, all of the objects serialized to the Derby catalogs are a
special extension of Externalizable, called Formatable. The Formatable
machinery was designed to run safely client-side as well as server-side.
Regardless of whether these objects are serialized across the network as
Formatables or as Strings, that serialized form can change between releases.
That's why there's a big warning in the Reference Guide that these objects are
not part of Derby's public API.
This particular bug report focuses on the AliasInfo object, which describes the
specifics of Derby routines. If the customer really needs the information
inside that object, it has been available for procedures in Derby's public api
since day 1 via DatabaseMetaData.getProcedureColumns(). For functions, the
information has been available in Derby's public api since 10.2.2.0 via
DatabaseMetaData.getFunctionColumns().
To add a little more context to this issue: I have run a 10.6 client (without
derby.jar in the classpath) against a 10.6 server and executed "select * from
sys.sysaliases". As long as I do not try to retrieve ALIASINFO via the
ResultSet, the query runs fine. I only see an exception if I explicitly use the
ResultSet methods to inspect the contents of ALIASINFO. I don't think that the
customer's problem is that they have carelessly issued "select *" when a
smaller select would do. I believe that the customer is explicitly looking at
the ALIASINFO column. It seems likely that they are using a non-public api to
extract information which is available via the public api. A very reasonable
response would be: "Don't do that. Use the public api instead."
Thanks,
-Rick
> With Derby 10.6 and higher, selecting object columns from system tables ERROR
> XN020: Error marshalling or unmarshalling a user defined type
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4688
> URL: https://issues.apache.org/jira/browse/DERBY-4688
> Project: Derby
> Issue Type: Task
> Components: Network Client
> Affects Versions: 10.7.0.0
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: releaseNote.html
>
>
> If derby.jar is not in the classpath when a client selects an object from a
> system table, for example selecting ALIASINFO from SYS.SYSALIASES an error
> will result, eg.
> ERROR XN020: Error marshalling or unmarshalling a user defined type:
> org.apache.
> derby.catalog.types.RoutineAliasInfo
> To reproduce, put only derbyclient.jar and derbytools.jar in your classpath
> and connect to a running server and run:
> ij> connect 'jdbc:derby://localhost:1527/wombat;create=trrue';
> ij> select * from sys.sysaliases
> > > ;
> ALIASID |ALIAS
> |SCHEMAID |JAVACLASSNAME
> |&|&|SYST&|ALIASINFO |SPECIFICNAME
> --------------------------------------------------------------------------------
> --------------------------------------------------------------------------------
> --------------------------------------------------------------------------------
> --------------------------------------------------------------------------------
> --------------------------------------------------------------------------------
> --------------------------------------------------------------------------------
> ------
> ERROR XN020: Error marshalling or unmarshalling a user defined type:
> org.apache.
> derby.catalog.types.RoutineAliasInfo
> ij>
> With the 10.5 client it gives the text of the procedure or function
> definition for ALIASINFO may have been useful to someone, e.g.
> SQLCAMESSAGE(IN SQLCODE INTEGER,IN SQLERRML SMALLINT,IN SQLERRMC
> VARCHAR(2400),I
> N SQLERRP CHAR(8),IN SQLERRD0 INTEGER,IN SQLERR&
> I am not sure what can or should be done about this issue. Workaround
> include:
> - Cast the value to LONG VARCHAR in the query.
> - Put the server jars in the classpath if you want to use the objects.
> - Remove extraneous columns if they are not used.
> I am not sure what can or should be done about this issue, but a release note
> would at least help mitigate it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
