From derby-dev-return-64760-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Nov 26 16:59:35 2008 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 84135 invoked from network); 26 Nov 2008 16:59:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Nov 2008 16:59:35 -0000 Received: (qmail 19973 invoked by uid 500); 26 Nov 2008 16:59:45 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 19953 invoked by uid 500); 26 Nov 2008 16:59:45 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 19942 invoked by uid 99); 26 Nov 2008 16:59:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Nov 2008 08:59:45 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Nov 2008 16:58:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4947B234C2A7 for ; Wed, 26 Nov 2008 08:58:44 -0800 (PST) Message-ID: <299682876.1227718724299.JavaMail.jira@brutus> Date: Wed, 26 Nov 2008 08:58:44 -0800 (PST) From: "Dag H. Wanvik (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-481) implement SQL generated columns MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651059#action_12651059 ] Dag H. Wanvik commented on DERBY-481: ------------------------------------- Reviewing derby-481-11-aa-notNull. Thanks for the good explanations, Rick, really helped! Good patch. Notes: Index: java/engine/org/apache/derby/impl/sql/execute/NormalizeResultSet.java Good that you refactored this class a bit; was a bit messy before.. * Javadoc for normalizeColumn starts with the text "Normalize a row". It should probably be "Normalize a column". What about the rest of that comment? It speaks of not yet having data type conversions.. Is this still relevant? We do have casts, but maybe this is something else. Asking since you touched it by moving it around ;-) * I think the normalizeColumn method should take sourceCol as an argument, rather than sourceRow (less scope; only one column is ever used inside normalizeColumn). * normalizeColumn javadoc lacks @params and @return. * private member numColumns is no longer needed. * computeStartColumn lacks @return and @params. Index: java/engine/org/apache/derby/impl/sql/execute/NoRowsResultSetImpl.java * would be nice to comment usage of new members firstColumn, generatedColumnPositions, normalizedGeneratedValues * maybe I am missing something here, but couldn't the two conditional actions below be put inside one 'if' in that they always happen together? if ( firstColumn < 0 ) { firstColumn = NormalizeResultSet.computeStartColumn( isUpdate, activation.getResultDescription() ); } if ( generatedColumnPositions == null ) { setupGeneratedColumns( activation, (ValueRow) newRow ); } * Javadoc for setupGeneratedColumns could use some more explanation, a bit on the concise side now, I think. It has side-effects. * The javadoc for ResultColumn#hasGenerationClause can now refer to the javadoc in the interface ResultColumnDescriptor (to avoid redundancy in description). > 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.