You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/07/10 22:33:04 UTC
[jira] Created: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
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
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.
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511565 ]
Daniel John Debrunner commented on DERBY-2917:
----------------------------------------------
Changing this would lead to TypeId and DataTypeDescriptor not being formattable (I think).
The serialized form of DataTypedescriptor writes out duplicate information
TypeId
BaseTypeIdImpl <<< duplicate of information written out by TypeDescriptorImpl
TypeDescriptorImpl
BaseTypeIdImpl
<type attributes>
A DataTypedescriptor can be fully recreated from its TypeDescriptor(Impl), thus there is no need to write out anything else.
Once DataTypedescriptor becomes only a runtime representation of the type, then all persistent types would be written out as a TypeDescriptor,
using DataTypedescriptor.getCatalogType() as required.
> 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.
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
Posted by "Robert Yokota (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605783#action_12605783 ]
Robert Yokota commented on DERBY-2917:
--------------------------------------
I wasn't able to isolate a test case, but I got the following ClassCastException when doing a hard upgrade from a 10.2.1.6 database to a 10.4.1.3 database. It looks like it's related to changes made for this JIRA issue.
2008-06-12 07:15:53.633 GMT Thread[DRDAConnThread_15,5,derby.daemons] Cleanup action starting
java.sql.SQLException: Failed to start database '/usr/ironhide/var/db/orcmon/derby', see the next exception for details.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
Caused by: java.sql.SQLException: Failed to start database '/usr/ironhide/var/db/orcmon/derby', see the next exception for details.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 17 more
Caused by: java.sql.SQLException: Exception during restore of a serializable or SQLData object of class
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
... 14 more
Caused by: ERROR XSDA8: Exception during restore of a serializable or SQLData object of class
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(Unknown Source)
at org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFromSlot(Unknown Source)
at org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapScan.fetchNext(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaHeap(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getAllSPSDescriptors(Unknown Source)
at org.apache.derby.impl.sql.catalog.DD_Version.dropJDBCMetadataSPSes(Unknown Source)
at org.apache.derby.impl.sql.catalog.DD_Version.doFullUpgrade(Unknown Source)
at org.apache.derby.impl.sql.catalog.DD_Version.upgradeIfNeeded(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.loadDictionaryTables(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
... 14 more
Caused by: java.io.StreamCorruptedException: java.lang.ClassCastException: org.apache.derby.catalog.types.OldRoutineType cannot be cast to org.apache.derby.iapi.ty
pes.DataTypeDescriptor
at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
at org.apache.derby.impl.sql.GenericResultDescription.readExternal(Unknown Source)
at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
at org.apache.derby.impl.sql.GenericStorablePreparedStatement.readExternal(Unknown Source)
at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
... 38 more
> 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.
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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 catalogs:
SYSALIASES - ALIASINFO column as fields with a RoutineAliasInfo (parameter types and return types)
SYSCOLUMNS - COLUMNDATATYPE
-----------------------------------------------------------------------------------------------------------------------
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 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.
[jira] Commented: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (DERBY-2917) Refactor DataTypeDescriptor and
TypeDescriptor to result in cleaner code.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner reassigned DERBY-2917:
--------------------------------------------
Assignee: Daniel John Debrunner
> 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.