db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6117) Extend the Table Functions java interface to pass more query context information from Derby
Date Sun, 26 Jan 2014 23:21:37 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-6117:

    Attachment: derby-6117-01-aa-AwareVTI.diff

´╗┐´╗┐Attaching derby-6117-01-aa-AwareVTI.diff. This patch introduces the AwareVTI interface.
This is a first step toward giving table functions more context about their execution environments.
I am running tests now.

Introduces two new classes/interfaces:

o VTIContext - This is a simple class which contains the following information:

  - The name of the schema holding the table function.
  - The non-schema-qualified name of the table function.
  - The text of the statement invoking the table function.

o AwareVTI - Table functions which implement this interface are handed the VTIContext describing
their execution environment.

VTITemplate now implements AwareVTI so most table functions will get this functionality for

VTIContext exposes the following methods:

    /** Return the name of the schema holding the table function */
    public  String  vtiSchema() { return _vtiSchema; }

    /** Return the unqualified table function name */
    public  String  vtiTable()  { return _vtiTable; }

    /** Return the text of the statement which invoked the table function */
    public  String  statementText() { return _statementText; }

AwareVTI contains these method:

    /** Get the table function context */
    public  VTIContext  getContext();

    /** Set the table function context */
    public  void    setContext( VTIContext context );

Touches the following files:


A       java/engine/org/apache/derby/vti/VTIContext.java
A       java/engine/org/apache/derby/vti/AwareVTI.java
M       java/engine/org/apache/derby/vti/VTITemplate.java

Introduces the new classes and wires them into most existing table functions.


M       java/engine/org/apache/derby/iapi/sql/execute/ResultSetFactory.java
M       java/engine/org/apache/derby/impl/sql/compile/MethodCallNode.java
M       java/engine/org/apache/derby/impl/sql/compile/FromVTI.java
M       java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java
M       java/engine/org/apache/derby/impl/sql/execute/GenericResultSetFactory.java
M       java/engine/org/apache/derby/impl/sql/execute/VTIResultSet.java

Compile-time and execution-time machinery to support VTIContext.


A       java/testing/org/apache/derbyTesting/functionTests/tests/lang/AwareVTITest.java
A       java/testing/org/apache/derbyTesting/functionTests/tests/lang/DummyAwareVTI.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java

Basic tests for this new feature.


M       tools/javadoc/publishedapi.ant

Adds AwareVTI and VTIContext to the public api.

> Extend the Table Functions java interface to pass more query context information from
> -------------------------------------------------------------------------------------------
>                 Key: DERBY-6117
>                 URL: https://issues.apache.org/jira/browse/DERBY-6117
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: David Vyvyan
>              Labels: derby_triage10_11
>         Attachments: derby-6117-01-aa-AwareVTI.diff
> General requirement is to extend the Table Functions java interface (through RestrictedVTI
or another interface) and pass more context information from Derby to Table Functions - esp
in query execution phase.
> Greater urgency is required for the first 2 items below, especially the ability to access
the original SQL which was available with VTIs. This is critical to the GaianDB project -
we extract HINTs from the query (where we pass meta data like user credentials), and also
extract full original complex predicate expressions (involving functions etc - which cannot
be expressed with a Restriction) - to push on in our query prorogation...
> In order of importance + simplicity:
> --------------------------------------------------
> 1 - Original SQL (this used to be available with VTIs through VTIEnvironment for both
compilation and execution phases)
> 2 - Name of function that was called
> 3 - User Info (ID, etc) - (this can currently be passed in the SQL hint)
> 4 - Richer predicate expressions (incl functions, etc)
> 5 - Context within Join query (e.g. inner or outer table, join type)
> 6 - Other Query Plan information
> 7 - Anything else...?

This message was sent by Atlassian JIRA

View raw message