You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/03/03 19:25:50 UTC
[jira] Created: (DERBY-2397) Dropping SQL objects could be improved
by reducing the number of classes required.
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.
[jira] Commented: (DERBY-2397) Dropping SQL objects could be
improved by reducing the number of classes required.
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477800 ]
Bryan Pendleton commented on DERBY-2397:
----------------------------------------
This sounds like a great idea. I struggled with several instances of this problem during ALTER TABLE testing.
> 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.
[jira] Assigned: (DERBY-2397) Dropping SQL objects could be
improved by reducing the number of classes required.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-2397:
-------------------------------------
Assignee: (was: Daniel John Debrunner)
> 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
>
> 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.
[jira] Commented: (DERBY-2397) Dropping SQL objects could be
improved by reducing the number of classes required.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-2397) Dropping SQL objects could be
improved by reducing the number of classes required.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.