[
https://issues.apache.org/jira/browse/DERBY-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875576#action_12875576
]
Kristian Waagan commented on DERBY-4688:
----------------------------------------
Including "server classes" in the client jar sounds like a delicate issue to me.
At the very least we should investigate how these classes will be serialized,
and maybe code the (de-)serialization logic ourselves (using Externalizable).
It is not clear to me how much more flexibility Externalizable gives us over
Serializable. To me it sounds acceptable if older client versions simply
displays the information they know about, ignoring the rest. This would allow
us to add new fields, but old/deprecated fields would have to be kept around
(setting it to null, empty string, or another appropriate value).
Also, what kind of functionality is required of these classes? Would basically
toString be enough?
> 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.