[
https://issues.apache.org/jira/browse/DERBY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477687
]
Daniel John Debrunner commented on DERBY-2397:
----------------------------------------------
The code to drop any descriptor representing a SQL object is a mix of OO fully
encapsulated dependencies and explicit knowledge/dependencies between objects.
A move to a pure OO fully encapsulated based upon the existing dependencies
would simplify the code.
As an example a drop of a table should simply invalidate all of its dependents
with a DROP_TABLE action, then dependent objects like triggers & constraints
would drop themselves and invalidate their dependencies. The drop code in the
table descriptor would be simply responsible for sending the invalidation and
then removing itself (the row in SYSTABLES) from the dictionary.
Currently the table descriptor knows about its triggers & constraints and drops
those explicitly (with some code that indicates it has hacks), but drops other
objects through the dependency system.
Having the drop logic for any descriptor encapsulated in the object itself is a
better OO model and can lead to smaller code and less buggy code.
As any change required in the drop logic is in one place rather than spread out
across many objects.
> Dropping SQL objects could be improved by reducing the number of classes
> required.
> ----------------------------------------------------------------------------------
>
> Key: DERBY-2397
> URL: https://issues.apache.org/jira/browse/DERBY-2397
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
>
> The current flow for a DROP statement, such as a DROP FUNCTION is roughly as
> follows:
> Compile time:
> c1) find the TupleDescriptor for the object to verify it exists
> (e.g. AliasDescriptor, TriggerDescriptor)
> c2) create an instance of a type specific ConstantAction (e.g.
> DropAliasConstantAction), information
> is passed into the ConstantAction to allow it to re-create
> the TupleDescriptor, but doesn't pass the actual TupleDescriptor.
> (E.g. the schema name, alias type and routine name is
> passed to the DropAliasConstantAction)
> Execute time (which may be sometime later than compile time) calls
> executeConstantAction on the object specific ConstantAction
> e1) execute verify a matching object exists by finding a
> matching TupleDescriptor
> e2) drop the object
> This could be simplified by utilizing the polymorphic nature of
> TupleDescriptors. Then all the DropXXXConstantActions could be replaced with
> a single DropDescriptorConstantAction that was created with a TupleDescriptor
> at compile time. Two new abstract methods would be added to
> TupleDescriptor, getCurrent() and drop().
> Then the execute steps would be:
> en1) Get the current TupleDescriptor using the getCurrent() method of
> the Tupledescriptor passed in at compile time.
> This method may return the same object, a different instance
> that refers to the same SQL object or an instance
> that refers to a different SQL object of the same name.
> descriptor = descriptor.getCurrent()
> en2) Drop the descriptor.
> descriptor.drop().
> Thus the checking and drop code would move from the SQL object specific
> ConstantActions into the SQL object specific TupleDescriptors and
> then all of the DropXXXConstantActions classes would be replaced with a
> single generic one. Thus removing around six classes.
> Grant/revoke changes has almost started this approach, where some instances
> of TupleDescriptor (e.g. ViewDescriptor) and the matching constant action
> to drop an item share code. This alerted me to the pattern that is really
> required, that of a drop() method in TupleDescriptor.
> I'll have a patch sometime over the weekend that shows an incremental
> approach for a couple of SQL objects.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
