[
https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-481:
--------------------------------
Attachment: derby-481-05-aa-update.diff
Attaching derby-481-05-aa-update.diff, the last chunk from the prototype patch.
I am running regression tests now.
This patch wires in UPDATE support for generated columns. As with INSERT, I
threaded my way through the UPDATE machinery largely by following the way that
CHECK constraints are handled.
UPDATE presents a couple extra issues in addition to the issues raised by
INSERT:
1) We don't have to enhance the target row with defaulted columns. Instead, we
have to enhance the update list with all generated columns whose generation
clauses reference columns in the update list.
2) If a generated column is added to the update list, then the columns it
references must be added to the list of columns which are read from the base
row.
3) The target row for UPDATE holds two copies of each column that either has to
be written or read: the before value of the column and the after value. This
gives rise to some trickiness.
Touches the following files:
------------------------------------------------------------------
-- BINDING AND CODE GENERATION
------------------------------------------------------------------
M java/engine/org/apache/derby/impl/sql/compile/UpdateNode.java
Adds generated columns to the update list if they are affected by the update.
For all generated columns in the update list, adds the columns they reference
to the list of columns to be read from disk. Forbids the setting of a generated
column to anything except the DEFAULT literal. Generates a method to fill in
computed columns at execution time--this is the (2') method described above in
the summary of patch derby-04-aa-insert.diff.
------------------------------------------------------------------
-- EXECUTION
------------------------------------------------------------------
M java/engine/org/apache/derby/iapi/sql/execute/ResultSetFactory.java
M
java/engine/org/apache/derby/impl/sql/execute/GenericResultSetFactory.java
Adds the (2') method as an argument to the factory methods that create
UpdateResultSets.
M java/engine/org/apache/derby/impl/sql/execute/UpdateResultSet.java
Invokes (2') close to where we invoke (3') already.
------------------------------------------------------------------
-- TESTS
------------------------------------------------------------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsTest.java
Uncommented basic tests for updates. Uncommented basic tests for the
interaction of generated columns with triggers and foreign keys.
> 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, 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.
