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

Reply via email to