Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 70877 invoked from network); 21 Nov 2005 16:51:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Nov 2005 16:51:15 -0000 Received: (qmail 81737 invoked by uid 500); 21 Nov 2005 16:51:14 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 81707 invoked by uid 500); 21 Nov 2005 16:51:14 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 81698 invoked by uid 99); 21 Nov 2005 16:51:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Nov 2005 08:51:14 -0800 Received-SPF: pass (asf.osuosl.org: local policy) Received: from [207.152.147.10] (HELO mailbox1.mosol.com) (207.152.147.10) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Nov 2005 08:52:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EEBB.BBB483F8" Subject: RE: [jira] Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables Date: Mon, 21 Nov 2005 11:50:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jira] Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables Thread-Index: AcXs2oqBYwToqxP/Rf+LVYUmtU0UXQB4R2uA From: "Westerfeld, Kurt" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EEBB.BBB483F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Was the syntax CREATE VIRTUAL TABLE implemented with these changes, or are they hard-wired for internal tables only now? =20 ________________________________ From: Myrna van Lunteren [mailto:m.v.lunteren@gmail.com]=20 Sent: Saturday, November 19, 2005 2:26 AM To: derby-dev@db.apache.org Subject: Re: [jira] Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic tables =20 Hi Dan, =20 To get this documented in the manuals, do we need an extra JIRA, or are you already taking care of this? =20 Myrna =20 On 11/18/05, Daniel John Debrunner (JIRA) wrote:=20 [ http://issues.apache.org/jira/browse/DERBY-571?page=3Dall ] Daniel John Debrunner closed DERBY-571: --------------------------------------- > Virtual Table Mapping for no argument Diagnostic tables > -------------------------------------------------------=20 > > Key: DERBY-571 > URL: http://issues.apache.org/jira/browse/DERBY-571 > Project: Derby > Type: Improvement=20 > 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.=20 > 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=20 > 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=20 > 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=20 > 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.=20 > 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.=20 > 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');=20 > - 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]=20 > 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=20 > 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 =20 =20 ------_=_NextPart_001_01C5EEBB.BBB483F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Was the syntax CREATE VIRTUAL TABLE implemented with = these changes, or are they hard-wired for internal tables only = now?

 

From: Myrna = van Lunteren [mailto:m.v.lunteren@gmail.com]
Sent: Saturday, November = 19, 2005 2:26 AM
To: derby-dev@db.apache.org
Subject: Re: [jira] = Closed: (DERBY-571) Virtual Table Mapping for no argument Diagnostic = tables

 

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) <derby-dev@db.apache.org> wrote:

    [ http:/= /issues.apache.org/jira/browse/DERBY-571?page=3Dall ]

Daniel John Debrunner closed DERBY-571:
---------------------------------------


> Virtual Table Mapping for no argument Diagnostic tables
> -------------------------------------------------------
>
>          Key: = DERBY-571
>          URL: http://issues.apa= che.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)
>           &nb= sp;LANGUAGE JAVA
>           &nb= sp;PARAMETER STYLE JAVA
>           &nb= sp;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

 

------_=_NextPart_001_01C5EEBB.BBB483F8--