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