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 Fri, 15 Dec 2006 20:17:28 GMT
     [ http://issues.apache.org/jira/browse/DERBY-2152?page=all ]

A B updated DERBY-2152:
-----------------------

    Attachment: d2152_engine_v1.patch
                d2152_testing_v1.patch
                d2152_v1.stat

Attaching a first attempt at a solution for this issue.  There are two patches involved:

  1. d2152_engine_v1.patch:  Changes to the Derby engine code to allow
     diagnostic VTI table mappings for VTIs that take parameters.

  2. d2152_testing_v1.patch: Addition of a new JUnit test class
     for testing the new VTI mappings.

The engine patch pretty much does what is written in the description for this issue: namely,
it allows the user to query the Derby diagnostic VTIs by using the following syntax:

  SELECT <rcList> from TABLE (SYSCS_DIAG.<vti-table-name> (<arg list>) )
    [ AS ] corrlationName

 Note that:

  a. We only support VTI table names in the SYSCS_DIAG schema
  b. The correlation name *is* required, though use of the "AS" keyword
     is optional (section 7.6 of the SQL 2003 spec, "<table primary>").
  c. The argument list can be empty.

The VTI table names that have been added are as follows:

  SYSCS_DIAG.SPACE_TABLE maps to org.apache.derby.diag.SpaceTable
  SYSCS_DIAG.ERROR_LOG_READER maps to org.apache.derby.diag.ErrorLogReader
  SYSCS_DIAG.STATEMENT_DURATION maps to org.apache.derby.diag.StatementDuration

Given all of that, the following are some areas/issues/questions for which I am hoping to
get feedback.  If anyone out there can review and/or provide insight/opinions on these, I'd
apprecate it.

  1. Since the argument list can be empty, a user now as two different ways
     to invoke diagnostic VTIs that take zero parameters.  Ex:

       A. As of DERBY-571:  SELECT * FROM SYSCS_DIAG.LOCK_TABLE
       B. With my patch:    SELECT * FROM TABLE (SYSCS_DIAG.LOCK_TABLE()) x

     Is it okay to have *both* of these syntaxes?  Note that, as it turns
     out, the only diagnostic VTI that does *not* allow zero arguments
     is SpaceTable; all of the other VTIs will have two different syntax
     variations that work.

  2. What error should we throw if the user specifies a table name that
     is not a valid VTI table-mapped name?  Ex.

       select * from TABLE (APP.T1()) x

     With the _v1 patch we'll throw a syntax error as follows:

       ERROR 42X01: Syntax error: APP.T1

     But that does not seem particularly helpful to me.  Should I add a new
     error message that gives more detail, or is this okay?  One other thing to
     note about this: in some cases, this error could be misleading.  Ex:

       set schema APP
       select * from TABLE (SPACE_TABLE('APP', 'T1')) x

     In this case we will throw a syntax error--but strictly speaking, this
     is _not_ a syntax error.  Rather, it's an error caused by the fact that
     SPACE_TABLE is not in the "APP" schema.  So if, for example, I did the
     following:

       set schema SYSCS_DIAG
       select * from TABLE (SPACE_TABLE('APP', 'T1')) x

     the SELECT statement now works fine.  Since the same statement works
     in one case and fails in the other, I don't think it's technically
     a syntax error.  Should I bother creating a new error message, then?

  3. When writing the JUnit test I took a look at some of the negative test
     cases in store/TransactionTable.sql.  I noticed that the following
     statement actually *works*:

       call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE(
           'SYSCS_DIAG', 'TRANSACTION_TABLE', 1, 1, 1);

     That statement works even without my changes.  But on the other
     hand, the COMPRESS_TABLE call (i.e. without the "INPLACE") throws
     an error (42X62) as I would expect.  Is this inconsistency a known
     issue, or should I file a separate Jira for this?  As things are
     now, the above call will "work" with all VTI table names (those from
     DERBY-571 and the ones I've added with my _v1 patch)--and again,
     please note that this is not the result of my changes.

  4. As a result of my changes there is one master update that is required.
     In lang/valuesclause.sql there is a slight diff in the error message
     for three queries.  With my patch the error message now shows a token
     where previously no token was given.  Ex:

       select * from  table target;
       < ERROR 42X01: Syntax error: Encountered "" at line 3, column 13.
       > ERROR 42X01: Syntax error: Encountered "target" at line 3, column 13.

     I assume this is okay, but if anyone feels otherwise, please let me know.

  5. The new JUnit test that I've added currently runs without a security
     manager.  The reason is that two of the VTIs--ErrorLogReader and
     StatementDuration--take as an (optional) argument the name of a log file
     as input.  I created a small test log file that I use for the tests, but
     when I tried running the JUnit test with a security manager, there was
     a failure when the VTI tried to read the log file.  My guess is that
     this is a separate bug--perhaps a privileged block missing somewhere in
     the VTI code?--but I would appreciate a second opinion.  For now I just
     have the test running with the security manager disabled; this can be
     changed when the permissions problem is resolved.

And of course, any other comments/suggestions would be much appreciated, as well.

> 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
>         Attachments: d2152_engine_v1.patch, d2152_testing_v1.patch, d2152_v1.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

        

Mime
View raw message