Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <10243770.1166557822613.JavaMail.jira@brutus>
Date: Tue, 19 Dec 2006 11:50:22 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2152) Support diagnostic vti tables that
 take parameters, such as SpaceTable
In-Reply-To: <30249954.1165345341004.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-2152?page=comments#action_12459739 ] 
            
Daniel John Debrunner commented on DERBY-2152:
----------------------------------------------

The separation looks good.
The javadoc comments for getVTIClassForTableFunction says 
   @param funcSchema Schema part of the function name if specified
but I think the schema name for the function will always be passed in, even if it isn't explicitly set in the SQL statement.

The lack of consistency between getVTIClassForTableFunction() and getVTIClassForTable() seems strange, though I can see why you did it that way. Once the code has been committed maybe some cleanup could be done, could be the old code to match the new code, or some other common ground. The differences are:

   - getVTIClassFor*() methods take different argument styles to represent the same information
   - one resolves the vti class outside the NewInvocationNode, one inside.

> Support diagnostic vti tables that take parameters, such as SpaceTable
> ----------------------------------------------------------------------
>
>                 Key: DERBY-2152
>                 URL: http://issues.apache.org/jira/browse/DERBY-2152
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Daniel John Debrunner
>         Assigned To: A B
>         Attachments: d2152_engine_v1.patch, d2152_engine_v2.patch, d2152_testing_v1.patch, d2152_testing_v2.patch, d2152_v1.stat, d2152_v2.stat
>
>
> Expand the work of DERBY-571 to support the remaining diagnostic tables that take parameters.
> Syntax would use the table constructor, like (not sure if an 'AS' clause will be required:
> select * from TABLE(SYSCS_DIAG.SPACE_TABLE(?, ?))
> Diagnostic VTIs that could be handled this way are:
> ErrorLogReader(String log file name)
> SpaceTable(String tableName)
> SpaceTable(String schemaName, String tableName)
> StatementDuration(String inputFileName)
> This is the second stage mentioned in DERBY-571

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira