[
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-02-aa-changeColumnNamesInStringColumnVTI.diff
Attaching derby-6117-02-aa-changeColumnNamesInStringColumnVTI.diff. This patch
makes it possible to create a StringColumnVTI with no column names and then set
the column names later. I am running tests now.
This feature is useful for AwareVTIs which determine their column names only
after analyzing their execution context.
Touches the following files:
---------------
M java/engine/org/apache/derby/vti/StringColumnVTI.java
If the StringColumnVTI is created without any column names, then the column
names can be set once later on.
---------------
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
New error raised if you try to change the column names after they've already
been set.
---------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/AwareVTITest.java
Test for this behavior.
> Extend the Table Functions java interface to pass more query context
> information from Derby
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-6117
> URL: https://issues.apache.org/jira/browse/DERBY-6117
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.8.3.0
> Reporter: David Vyvyan
> Labels: derby_triage10_11
> Attachments: derby-6117-01-aa-AwareVTI.diff,
> derby-6117-01-ab-AwareVTI.diff,
> derby-6117-02-aa-changeColumnNamesInStringColumnVTI.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
(v6.1.5#6160)
