db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2397) Dropping SQL objects could be improved by reducing the number of classes required.
Date Sat, 03 Mar 2007 21:06:51 GMT

    [ 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

> 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,
>              c2) create an instance of a type specific ConstantAction (e.g. DropAliasConstantAction),
>                    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
>     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.

View raw message