Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <11492672.1173241584564.JavaMail.root@brutus>
Date: Tue, 6 Mar 2007 20:26:24 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2397) Dropping SQL objects could be
 improved by reducing the number of classes required.
In-Reply-To: <22536803.1172946350672.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478682 ] 

Daniel John Debrunner commented on DERBY-2397:
----------------------------------------------

Having investigated a little more, moving to a pure-oo model has a couple of drawbacks:

  1) Additional on-disk footprint for objects to store dependencies where previously the dependency was "hard-coded" in the create & drop code.
      E.g. a view has a table descriptor and a view descriptor and no dependency exists between them in SYSDEPENDS, just in the code.

   2) Would need upgrade code to create on-disk dependencies (in SYSDEPENDS) where previously only hard-coded ones exist.

I think I will take this as far as it can go without hitting the above issues, i.e. only changes that do not require on-disk changes.
Some of this will include adding comments in the CreateXXXConstantActions that document what objects are created and what dependencies are created,
like the one I justed added in CreateViewConstantAction. This might make it easier to understand the code when implementing something like alter table.

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