db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2152) Support diagnostic vti tables that take parameters, such as SpaceTable
Date Tue, 19 Dec 2006 00:58:22 GMT
     [ http://issues.apache.org/jira/browse/DERBY-2152?page=all ]

A B updated DERBY-2152:

    Attachment: d2152_engine_v2.patch

Posting a second version of the patch, d2152_engine_v2.patch and d2152_testing_v2.patch, to
address Dan's review comments.  In particular this version of the patch separates VTI "tables"
(DERBY-571) from VTI "table functions".  So the following statement:

  select * from syscs_diag.space_table

will now throw error 42X05 ("table not found").  That's also what will happen for the other
table functions defined in this issue (namely, statement_duration and error_log_reader). 
Similarly, the following statement:

  select * from table (syscs_diag.lock_table())

will now throw error 42Y03 ("not recognized as a function or procedure").  That's also what
will happen for the other VTI tables defined in DERBY-571 (namely, statement_cache, transaction_table,
and error_messages).

To accomplish this separation the _v2 patches have the following changes from the _v1 patches:

  - Renamed the "getVTIClass()" method in DataDictionary to "getVTIClassForTable()"
  - Added new method, "getVTIClassForTableFunction()", to the DataDictionary
    interface and implementation classes.  The new method takes two strings:
    one for the schema name of the table function and one for the function name
    itself (ex. "space_table").  Also pushed the logic that checks the schema
    name (i.e. to make sure it is "SYSCS_DIAG") down into the new DataDictionary
    method, as mentioned in my previous comment.
  - Changed NewInvocation.java to call the new getVTIClassForTableFunction()
  - Changed the error thrown by NewInvocation for an invalid table function name
    to be error 42Y03 ("not recognized as a function or procedure") instead of
    a syntax error.
  - Added new test cases to the JUnit class to make sure that the correct errors
    are thrown if VTI tables are used in the TABLE constructor (42Y03) or if VTI
    table functions are used as base tables (42X05).  Also updated the expected
    SQLSTATEs for existing test cases as appropriate.

I ran deryall as a sanity check on Red Hat Linux with ibm142 and there were no failures.

I *think* this patch accomplishes the separation of "tables" from "table functions" that Dan
mentioned, but of course I could still be missing something.  Any review comments one way
or the other would be appreciated.

> 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


View raw message