You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2005/09/15 19:34:55 UTC

[jira] Created: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Virtual Table Mapping for no argument Diagnostic tables
-------------------------------------------------------

         Key: DERBY-571
         URL: http://issues.apache.org/jira/browse/DERBY-571
     Project: Derby
        Type: Improvement
  Components: SQL  
    Reporter: Daniel John Debrunner
 Assigned to: Daniel John Debrunner 
    Priority: Minor
     Fix For: 10.2.0.0


Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
These tables are invoked using an awkward, non-standard syntax. As an example:

SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE

The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
to the runtime virtual table code. Thus the above example would be replaced by:

SELECT * FROM SYSCS_DIAG.LOCK_TABLE

These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
can be used wherever a normal table can.

Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
will result in an exception.

The old style syntax will remain in place for 10.2, but become deprecated.

The tables to be implemented in this change are:

SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages

Adding such a table will be table driven, thus easy for others to provide additional diagnostics.

Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
The ResultSetMetaData for the any query involving a diagnostic table will be valid.

This is a first step in a progression towards supporing a fully application/user defined virtual table.

These steps are not part of this jira issue, but added for information purposes.

- second step - supporting diagnostic tables with parameters, e.g.

  SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');

- third step - providing a create virtual table statement (most databases support
   some form of virtual table, or wrappers). The DDL would be non-standard but the
   data access would be standard. [need to check table functions in part 13 of SQL standard]

   E.g. syntax yet to be defined, but to give the general idea
      CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
           LANGUAGE JAVA
           PARAMETER STYLE JAVA
           EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';








-- 
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


Re: [jira] Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by Myrna van Lunteren <m....@gmail.com>.
Hi Dan,
 To get this documented in the manuals, do we need an extra JIRA, or are you
already taking care of this?
 Myrna

 On 11/18/05, Daniel John Debrunner (JIRA) <de...@db.apache.org> wrote:
>
> [ http://issues.apache.org/jira/browse/DERBY-571?page=all ]
>
> Daniel John Debrunner closed DERBY-571:
> ---------------------------------------
>
>
> > Virtual Table Mapping for no argument Diagnostic tables
> > -------------------------------------------------------
> >
> > Key: DERBY-571
> > URL: http://issues.apache.org/jira/browse/DERBY-571
> > Project: Derby
> > Type: Improvement
> > Components: SQL
> > Reporter: Daniel John Debrunner
> > Assignee: Daniel John Debrunner
> > Priority: Minor
> > Fix For: 10.2.0.0 <http://10.2.0.0>
>
> >
> > Currently four no-argument diagnostic tables exist that provide
> information about the running state of Derby, or its error messages.
> > These tables are invoked using an awkward, non-standard syntax. As an
> example:
> > SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> > The improvement will provide an internal mapping from a regular table
> name in the SYSCS_DIAG schema
> > to the runtime virtual table code. Thus the above example would be
> replaced by:
> > SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> > These diagnostic table expressions are regular table expressions (as is
> the NEW VTI construct) and
> > can be used wherever a normal table can.
> > Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that
> references a diagnostic table
> > will result in an exception.
> > The old style syntax will remain in place for 10.2, but become
> deprecated.
> > The tables to be implemented in this change are:
> > SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable
> > SYSCS_DIAG.STATEMENT_CACHE replaces org.apache.derby.diag.StatementCache
> > SYSCS_DIAG.TRANSACTION_TABLE replaces
> org.apache.derby.diag.TransactionTable
> > SYSCS_DIAG.ERROR_MESSAGES replaces org.apache.derby.diag.ErrorMessages
> > Adding such a table will be table driven, thus easy for others to
> provide additional diagnostics.
> > Information about these diagnostic tables will not appear in the system
> catalogs or JDBC DatabaseMetaData.
> > The ResultSetMetaData for the any query involving a diagnostic table
> will be valid.
> > This is a first step in a progression towards supporing a fully
> application/user defined virtual table.
> > These steps are not part of this jira issue, but added for information
> purposes.
> > - second step - supporting diagnostic tables with parameters, e.g.
> > SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> > - third step - providing a create virtual table statement (most
> databases support
> > some form of virtual table, or wrappers). The DDL would be non-standard
> but the
> > data access would be standard. [need to check table functions in part 13
> of SQL standard]
> > E.g. syntax yet to be defined, but to give the general idea
> > CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END
> TIMESTAMP)
> > LANGUAGE JAVA
> > PARAMETER STYLE JAVA
> > EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';
>
> --
> 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
>
>

[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Eric Radzinski (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12365663 ] 

Eric Radzinski commented on DERBY-571:
--------------------------------------

Does this issue require some documentation (e.g., do the four new system tables need to be doc'd in the Ref Guide?)

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Resolved: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-571?page=all ]
     
Daniel John Debrunner resolved DERBY-571:
-----------------------------------------

    Resolution: Fixed

Last set of changes checked in for the framework and no argument diagnostic tables.

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-571?page=all ]
     
Daniel John Debrunner closed DERBY-571:
---------------------------------------


> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Eric Jain (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12356073 ] 

Eric Jain commented on DERBY-571:
---------------------------------

If such virtual tables could be used to integrate Lucene search results with data in relational tables (e.g. for summaries and sorting), that would be a killer feature for Derby!

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12368513 ] 

Daniel John Debrunner commented on DERBY-571:
---------------------------------------------

Sorry missed the earlier requests:

The tables to be documented are listed in the descripton.

SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable
SYSCS_DIAG.STATEMENT_CACHE replaces org.apache.derby.diag.StatementCache
SYSCS_DIAG.TRANSACTION_TABLE replaces org.apache.derby.diag.TransactionTable
SYSCS_DIAG.ERROR_MESSAGES replaces org.apache.derby.diag.ErrorMessages 

The information about the tables can be found in the javadoc for the class listed above.
That can be found at:

http://db.apache.org/derby/javadoc/engine/

click on the org.apache.derby.diag link in the Packages table, then select each class, e.g. LockTable to see the info.

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Jeff Levitt (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12368962 ] 

Jeff Levitt commented on DERBY-571:
-----------------------------------

I looked, and our current doc does not have any information for any of the now replaced org.apache.derby.diag.<whatever> tables.  Do we want a new section to document the SYSCS_DIAG.<whatever> tanles, and if so, where and in which manual?  Or is the javadoc satisfactory?

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12369042 ] 

Daniel John Debrunner commented on DERBY-571:
---------------------------------------------

New section similar to the system tables section in the reference manual.

There is no public javadoc for these classes, only internal.

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Jeff Levitt (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12368401 ] 

Jeff Levitt commented on DERBY-571:
-----------------------------------

Eric recently asked if there are any tables to doc for this.  I second that motion.  Could someone please provide information so that this can get documented?  Thanks!

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement
>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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


[jira] Commented: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables

Posted by "Stan Bradbury (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12420139 ] 

Stan Bradbury commented on DERBY-571:
-------------------------------------

Intending to open a documentation sub-task on this - no open issue found regarding docuementing the diagnostic tables of SYSCS_DIAG.  Minimally the existance of the schema and tables need to be listed.  

> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: DERBY-571
>          URL: http://issues.apache.org/jira/browse/DERBY-571
>      Project: Derby
>         Type: Improvement

>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> Currently four no-argument diagnostic tables exist that provide information about the running state of Derby, or its error messages.
> These tables are invoked using an awkward, non-standard syntax. As an example:
> SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
> The improvement will provide an internal mapping from a regular table name in the SYSCS_DIAG schema
> to the runtime virtual table code. Thus the above example would be replaced by:
> SELECT * FROM SYSCS_DIAG.LOCK_TABLE
> These diagnostic table expressions are regular table expressions (as is the NEW VTI construct) and
> can be used wherever a normal table can.
> Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a diagnostic table
> will result in an exception.
> The old style syntax will remain in place for 10.2, but become deprecated.
> The tables to be implemented in this change are:
> SYSCS_DIAG.LOCK_TABLE   replaces org.apache.derby.diag.LockTable
> SYSCS_DIAG.STATEMENT_CACHE    replaces org.apache.derby.diag.StatementCache
> SYSCS_DIAG.TRANSACTION_TABLE    replaces org.apache.derby.diag.TransactionTable
> SYSCS_DIAG.ERROR_MESSAGES    replaces org.apache.derby.diag.ErrorMessages
> Adding such a table will be table driven, thus easy for others to provide additional diagnostics.
> Information about these diagnostic tables will not appear in the system catalogs or JDBC DatabaseMetaData.
> The ResultSetMetaData for the any query involving a diagnostic table will be valid.
> This is a first step in a progression towards supporing a fully application/user defined virtual table.
> These steps are not part of this jira issue, but added for information purposes.
> - second step - supporting diagnostic tables with parameters, e.g.
>   SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
> - third step - providing a create virtual table statement (most databases support
>    some form of virtual table, or wrappers). The DDL would be non-standard but the
>    data access would be standard. [need to check table functions in part 13 of SQL standard]
>    E.g. syntax yet to be defined, but to give the general idea
>       CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END TIMESTAMP)
>            LANGUAGE JAVA
>            PARAMETER STYLE JAVA
>            EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';

-- 
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