[ 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
