[
https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786715#action_12786715
]
Rick Hillegas edited comment on DERBY-651 at 12/7/09 1:19 PM:
--------------------------------------------------------------
Attaching derby-651-05-ac-dependencyTable.diff. This adds persistent dependency
tracking between tables and the UDT types of their columns. This patch prevents
you from dropping a UDT if there are tables whose columns rely on that type.
Regression tests passed cleanly for me.
Ideally, we would like to track these dependencies at column granularity.
However, columns don't have UUIDs. UUIDs identify the tuple descriptors which
are endpoints of arcs in the dependency graph. The following design choice had
to be made:
1) Create UUIDs for every column.
2) Track the dependency at a higher level, drawing the arcs between tables and
UDTs rather than between columns and UDTs.
Option (1) looked like a lot of work with a high probability of destabilizing
the codeline. I opted for (2) instead. This ended up pushing some complexity
into one localized method: DDLConstantAction.adjustUDTDependencies(). That
method is responsible for making sure that there is only one dependency arc
between a table and a UDT, regardless of how many columns in the table may
share that UDT type.
Touches the following files:
M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java
M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java
M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
M java/engine/org/apache/derby/catalog/types/BaseTypeIdImpl.java
Adds a dictionary method for looking up the AliasDescriptor associated with a
UDT. This AliasDescriptor is the persistent object that is one of the endpoints
of a dependency arc.
M java/engine/org/apache/derby/iapi/sql/depend/DependencyManager.java
M java/engine/org/apache/derby/impl/sql/depend/BasicDependencyManager.java
M java/engine/org/apache/derby/iapi/sql/dictionary/AliasDescriptor.java
Boilerplate to support DROP TYPE.
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
New error message raised when a dependent table prevents a UDT from being
dropped.
M java/engine/org/apache/derby/impl/sql/compile/TableElementNode.java
Made DROP COLUMN nodes report that they are DROP COLUMN nodes rather than
MODIFY COLUMN nodes. Some of the DROP COLUMN logic was being skipped.
M java/engine/org/apache/derby/iapi/sql/dictionary/TableDescriptor.java
Made it possible for a table to be the starting point of a dependency arc.
Previously, a table could only be the ending point of a dependency arc.
M java/engine/org/apache/derby/impl/sql/compile/TableElementList.java
M
java/engine/org/apache/derby/impl/sql/execute/CreateTableConstantAction.java
M java/engine/org/apache/derby/impl/sql/execute/DDLConstantAction.java
M
java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.java
This is the heart of the logic which adds and drops the dependency arc from a
table to a UDT.
M java/engine/org/apache/derby/impl/sql/compile/AlterTableNode.java
M java/engine/org/apache/derby/impl/sql/compile/ColumnDefinitionNode.java
M java/engine/org/apache/derby/impl/sql/compile/CreateTableNode.java
More debug machinery for printing out the contents of DDL nodes in the AST.
Debug support for DDL nodes seems weak.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/UDTTest.java
Basic tests to verify that if a table has a UDT column then that UDT cannot be
dropped.
was (Author: rhillegas):
Attaching derby-651-05-ac-dependencyTable.diff. This adds persistent
dependency tracking between tables and the UDT types of their columns. This
patch prevents you from dropping a UDT if there are tables whose columns rely
on that type.
Ideally, we would like to track these dependencies at column granularity.
However, columns don't have UUIDs. UUIDs identify the tuple descriptors which
are endpoints of arcs in the dependency graph. The following design choice had
to be made:
1) Create UUIDs for every column.
2) Track the dependency at a higher level, drawing the arcs between tables and
UDTs rather than between columns and UDTs.
Option (1) looked like a lot of work with a high probability of destabilizing
the codeline. I opted for (2) instead. This ended up pushing some complexity
into one localized method: DDLConstantAction.adjustUDTDependencies(). That
method is responsible for making sure that there is only one dependency arc
between a table and a UDT, regardless of how many columns in the table may
share that UDT type.
Touches the following files:
M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java
M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java
M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
M java/engine/org/apache/derby/catalog/types/BaseTypeIdImpl.java
Adds a dictionary method for looking up the AliasDescriptor associated with a
UDT. This AliasDescriptor is the persistent object that is one of the endpoints
of a dependency arc.
M java/engine/org/apache/derby/iapi/sql/depend/DependencyManager.java
M java/engine/org/apache/derby/impl/sql/depend/BasicDependencyManager.java
M java/engine/org/apache/derby/iapi/sql/dictionary/AliasDescriptor.java
Boilerplate to support DROP TYPE.
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
New error message raised when a dependent table prevents a UDT from being
dropped.
M java/engine/org/apache/derby/impl/sql/compile/TableElementNode.java
Made DROP COLUMN nodes report that they are DROP COLUMN nodes rather than
MODIFY COLUMN nodes. Some of the DROP COLUMN logic was being skipped.
M java/engine/org/apache/derby/iapi/sql/dictionary/TableDescriptor.java
Made it possible for a table to be the starting point of a dependency arc.
Previously, a table could only be the ending point of a dependency arc.
M java/engine/org/apache/derby/impl/sql/compile/TableElementList.java
M
java/engine/org/apache/derby/impl/sql/execute/CreateTableConstantAction.java
M java/engine/org/apache/derby/impl/sql/execute/DDLConstantAction.java
M
java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.java
This is the heart of the logic which adds and drops the dependency arc from a
table to a UDT.
M java/engine/org/apache/derby/impl/sql/compile/AlterTableNode.java
M java/engine/org/apache/derby/impl/sql/compile/ColumnDefinitionNode.java
M java/engine/org/apache/derby/impl/sql/compile/CreateTableNode.java
More debug machinery for printing out the contents of DDL nodes in the AST.
Debug support for DDL nodes seems weak.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/UDTTest.java
Basic tests to verify that if a table has a UDT column then that UDT cannot be
dropped.
> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff,
> derby-651-02-af-udtColumnsRetvalsParams.diff,
> derby-651-03-aa-udttestInstability.diff, derby-651-04-aa-javadoc.diff,
> derby-651-05-ac-dependencyTable.diff, UserDefinedTypes.html,
> UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table"
> on October 26, 2005 requests the ability to store java objects in the
> database.
> Old releases of Cloudscape allow users to declare a column's type to be a
> Serializable class. This feature was removed from Derby because the syntax
> was non-standard. However, most of the machinery to support objects
> serialized to columns is still in Derby and is even used in system tables. We
> need to agree on some standard syntax here and re-expose this useful feature.
> Some subset of the ANSI adt syntax, cumbersome as it is, would do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
