[
https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648477#action_12648477
]
Dag H. Wanvik commented on DERBY-481:
-------------------------------------
Reviewed derby-481-04-aa-insert. Quite a mouthful, this one :) Looks
good, though. Thanks for the detailed explanation of the code; very
helpful. I wasn't able to locate the "similar poking" being done for
the CHECK codepaths; could you point me to that?
Minor notes:
M java/engine/org/apache/derby/impl/sql/compile/ResultSetNode.java
- I think createGeneratedColumn can be simplified by using arg
getNullNode(colDesc.getType()) instead of the dummy declaration?
M java/engine/org/apache/derby/impl/sql/compile/DMLModStatementNode.java
- javadocs for forbidGenerationOverrides, parseAndBindGenerationClauses
and generateGenerationClauses lack @params
- The "continue" statement after hasGenerationClauses has been
established as true can be replaced by a break; no need to see more.
The initial comment in this loop ("generate statements of the
form..") seem misplaced too, since this loop is only used to detect
is there exists a generation clause. It should probably be moved to
after the loop?
- I see you have just followed the pattern from check constraints, but
I am not sure I like the fact that there are two overloaded public
methods called generateGenerationClauses which seem to be on
different levels of abstraction. The innermost can be private,
btw. I would have preferred different names for them.
M java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
- has lots of spurious diffs; only one significant change.
M java/engine/org/apache/derby/impl/sql/execute/NoRowsResultSetImpl.java
- The method evaluateGenerationClauses could be made protected and
moved down to DMLWriteResultSet. It lacks @params for its javadoc.
> 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,
> 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.
