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