[
https://issues.apache.org/jira/browse/CALCITE-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761498#comment-17761498
]
Oliver Lee commented on CALCITE-5964:
-------------------------------------
Hey [~julianhyde]
I've added a commit here (very rough, not tidied up yet) but would love to get
some feedback before I go ahead and make the parallel changes to support
getColumns as well.
[https://github.com/looker-open-source/calcite/pull/37/commits/513f3da154954bbe48f67d9fd9c0e5089c86c34b#diff-202586edbf28484a3a4c1498d8f61096e7a12c0a9c813260fb4282b5c19a3e96]
Since discovering that Avatica itself does not need to be changed to handle
responses of additional shapes, the changes would be in Calcite to support
handling subclasses. My Avatica PR will just include my tests.
My idea is to pass in a subclass of {{CalciteMetaTable}} when instantiating
{{{}CalciteMetaImpl{}}}, passed in through the {{connection.info}} (
{{CalciteConnectionProperty}} ) and use that defined subclass to create
enumerables. The subclass will contain additional attributes that hold the
additional metadata.
The subclass would have the requirements of having the same constructor shape
as CalciteMetaTable,
{quote}{{CalciteMetaTable(Table calciteTable, String tableCat, String
tableSchem, String tableName)}}
{quote}
and also have to extend CalciteMetaTable. It will also have to provide a
function override for {{getColumnNames()}} to list out all of the class'
attributes (in the correct order) which is used for reflection and creating the
list of {{ColumnMetaData}} for the Signature.
> Support additional metadata attributes in GET_TABLES and GET_COLUMNS
> --------------------------------------------------------------------
>
> Key: CALCITE-5964
> URL: https://issues.apache.org/jira/browse/CALCITE-5964
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
> Reporter: Oliver Lee
> Assignee: Oliver Lee
> Priority: Major
>
> The goal is to add to Avatica a mechanism such that additional metadata
> fields pertaining to tables and columns can be transmitted alongside the
> standard JDBC
> [getTables|https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-)]
> and {{getColumns}} calls.
> The Avatica client needs the response to be extensible such that revisions to
> metadata fields send and future additions does not require a new JAR file.
> Requirements:
> # Avatica user does not need to download new jar files if the server decides
> to send over new metadata data in the future
> # If the client makes modifications to support additional columns, they
> should always be present in the call and appear with null values, as opposed
> to complete omission (Number of columns in response stays the same)
> # Can handle attributes of varying types i.e. {{numberOne: int}} and
> {{booleanOne: boolean}}
> # Allows value retrieval from the {{ResultSet}} through calling
> {{resultSet.getInt(“booleanOne”)}} or {{resultSet.getBoolean(“booleanOne”)}}
> Current proposal is to modify the {{MetaTable}} and {{MetaColumn}} classes to
> include a map.
> {{{}HashMap<String, Object>{}}}, such that when instantiating the
> {{CalciteMetaTable}} in the {{{}ResultSet{}}}, new entries could be added in
> the future without changes to Avatica.
> One we have a list of additional metadata fields to be emitted in
> {{{}CalciteMetaImpl{}}}, the {{ResultSet}} would be created with the
> appropriate values.
>
> There are still some challenges identified below and I would love some input:
> Challenges:
> * Currently the {{MetaTable}} class that is instantiated is a
> {{{}CalciteMetaImpl{}}}. For the {{getTables()}} call, the response will be a
> list composed of schema tables of class {{CalciteMetaTable}} and database
> tables which can potentially be overloaded into 1 or more different
> subclasses. From this one heterogeneous list, we must determine the full list
> of columns to be included in the additional metadata hash. My initial plan
> was to provide a function in Calcite’s {{Table}} class such as
> {{getAdditionalColumns}} and allow it to be overloaded, but then I discovered
> the heterogeneity of the list.
> * Modifying the MetaTable class to include the hashmap of values could be
> easily done, but the challenge lies at {{{}RemoteMeta{}}}, to be able to
> serialize this cleanly so that requirement (4) is met and users can retrieve
> the values nicely. {{RemoteMeta}} currently serializes the response using
> reflection by looking at MetaTable.class and its attributes. The addition of
> one map is not immediately compatible with iterating over the keys of the map
> and turning each of those into fields. I’m looking into the idea of
> processing the enumerable in {{CalciteMetaImpl}} before the Frame gets created
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
