db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
Date Fri, 01 Feb 2008 23:01:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564968#action_12564968

Daniel John Debrunner commented on DERBY-2917:

Note on upgrade from older releases:

Objects that are org.apache.derby.catalog.TypeDescriptor can be stored in these two system

SYSALIASES - ALIASINFO column as fields with a RoutineAliasInfo (parameter types and return

SYSCOLUMNS.COLUMNDATATYPE is always populated with a TypeDescriptorImpl which is the simple
correct form of TypeDescriptor for catalogs.
   SYSCOLUMNSRowFactory has enforced this since the code was contributed. Thus there are no
upgrade issues for this catalog.

SYSALIASES - ALIASINFO is populated with the runtime DataTypeDescriptor in releases older
than 10.4, thus their on-disk format for a RoutineAliasInfo uses the serialized version that
includes duplicate information (see earlier comment). Some upgrade code might be needed for
10.4 to cope with this format.

> Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
> -------------------------------------------------------------------------
>                 Key: DERBY-2917
>                 URL: https://issues.apache.org/jira/browse/DERBY-2917
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services, SQL
>            Reporter: Daniel John Debrunner
>            Assignee: Daniel John Debrunner
> TypeDescriptor ideally represents a catalog type (column in a table, parameter in a procedure
> DataTypeDescriptor represents a runtime type
> Currently DataTypeDescriptor  extends (implements) TypeDescriptor , but the relationship
would be cleaner if DataTypeDescriptor  had a TypeDescriptor (but was not a TypeDescriptor).
> One can at the moment obtain a TypeDescriptor from a DataTypeDescriptor  using DataTypeDescriptor.getCatalogType()
but most code just treats DataTypeDescriptor   as a TypeDescriptor. This has lead to a couple
of issues:
> 1) When a routine's parameter/return type is written out a DataTypeDescriptor is written
to disk. This results in type information being repeated in the serialized form, thus increasing
the on-disk size of a Derby database.
> 2) Collation derivation is runtime only (all persistent types by definition have implicit
type) but the derivation is on the catalog Typedescriptor interface.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message