db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and TypeDescriptor to result in cleaner code.
Date Tue, 10 Jul 2007 21:10:05 GMT

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

Rick Hillegas commented on DERBY-2917:
--------------------------------------

Thanks for tackling this, Dan. I find Derby's type system to be very puzzling. Cleaning up
just this portion of it would be a great service. It is particularly odd that the types actually
stored in the catalogs (for function return values at least) are not catalog types. There
are a bewildering number of interfaces and classes which cooperate here: TypeIds, Formatable
Ids, TypeDescriptors, DataTypeDescriptors. Then there are multiple type systems at work: the
Java type system, the SQL type system, the Derby catalog type system, and the Derby runtime
type system.

It seems to me that one ought to be able to get by with just one type system that is rich
enough to be usable all across Derby. It should be possible to collapse TypeIds, FormatableIds,
TypeDescriptors, and DataTypeDescriptors into a single concept. I suspect that a lot of the
confusion arose long ago because the division of labor between datatypes and datavalues was
not very satisfactory.

> 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
etc.)
> 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.


Mime
View raw message