db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-481) implement SQL generated columns
Date Tue, 25 Nov 2008 18:23:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650666#action_12650666
] 

Dag H. Wanvik commented on DERBY-481:
-------------------------------------

Reviewed patch derby-481-10-aa-foreignKeyActions. Looks correct to
me. Thanks, Rick!

My notes:
* error messages

  '{0}' is a generated column. It cannot be part of a foreign key whose
  referential action is SET NULL or SET DEFAULT or whose update rule is
  ON UPDATE CASCADE

  Would perhaps be better to say "referential action for delete is SET
  NULL or SET DEFAULT or whose referential action for update is
  CASCADE" to make the the two cases more symmetrically explained. As
  it stands, the first part doesn't explicitly say this concerns ON
  DELETE.

* AlterTableNode.java

  This code fragment:
  :
  if  (numGenerationClauses > 0)
  { tableElementList.bindAndValidateGenerationClauses(fromList, generatedColumns ); }
  if ( numReferenceConstraints > 0) { tableElementList.validateForeignKeysOnGenerationClauses(
fromList, generatedColumns ); }

The latter if statement could be conditional on numGenerationClauses > 0, too,
I think

  if  (numGenerationClauses > 0) { 
     tableElementList.bindAndValidateGenerationClauses(
         fromList, generatedColumns ); 

     if (numReferenceConstraints > 0) { 
         tableElementList.validateForeignKeysOnGenerationClauses(
             fromList, generatedColumns ); }
  }

Even if validateForeignKeysOnGenerationClauses tests for the presence
of generation clauses, it seems more logical to me to just not call
it. 

Ditto in CreateTableNode.java.

* TableElementList.java
- typo: "rulse" -> rule
- This logic
            if (
                ( deleteRule != StatementType.RA_SETNULL ) &&
                ( deleteRule != StatementType.RA_SETDEFAULT )
                )
            { continue; }

  I think is more readable as:

            if( ! (deleteRule == StatementType.RA_SETNULL ||
                   deleteRule == StatementType.RA_SETDEFAULT ) )
            { continue }

  Ideally, though, I would prefer

            if( deleteRule == StatementType.RA_SETNULL ||
                deleteRule == StatementType.RA_SETDEFAULT ) {
               // do our thing
            } else {
               continue
            }

in spite of the extra indentation, but that's me... ;)

* GeneratedColumnsTest.java

Thanks for the extra tests! Cf. DERBY-3964 though.


> implement SQL generated columns
> -------------------------------
>
>                 Key: DERBY-481
>                 URL: https://issues.apache.org/jira/browse/DERBY-481
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.0.2.1
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-481-00-aa-prototype.diff, derby-481-01-aa-catalog.diff, derby-481-02-aa-utilities.diff,
derby-481-03-aa-grammar.diff, derby-481-04-aa-insert.diff, derby-481-05-aa-update.diff, derby-481-06-aa-genreferences.diff,
derby-481-07-aa-noSQLinRoutines.diff, derby-481-07-ab-noSQLinRoutines.diff, derby-481-08-aa-castToDeclaredType.diff,
derby-481-09-aa-dummyDefaults.diff, derby-481-10-aa-foreignKeyActions.diff, derby-481-11-aa-notNull.diff,
derby-481-12-aa-padding.diff, derby-481-13-aa-alterDatatype.diff, derby-481-14-ab-dropColumn.diff,
derby-481-15-aa-renameAndAddDefault.diff, derby-481-16-aa-dropFunction.diff, derby-481-17-aa-currentSchema.diff,
derby-481-18-aa-updatableResultSets.diff, derby-481-19-aa-cleanup.diff, GeneratedColumns.html,
GeneratedColumns.html, GeneratedColumns.html
>
>
> Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the
performance requirements of Expression Indexes (bug 455). Generated columns may not be as
elegant as Expression Indexes, but they are easier to implement. We would allow the following
new kind of column definition in CREATE TABLE and ALTER TABLE statements:
>     columnName GENERATED ALWAYS AS ( expression )
> If expression were an indexableExpression (as defined in bug 455), then we could create
indexes on it. There is no work for the optimizer to do here. The Language merely has to compute
the generated column at INSERT/UPDATE time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message