[
https://issues.apache.org/jira/browse/CALCITE-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759769#comment-17759769
]
Julian Hyde commented on CALCITE-5964:
--------------------------------------
Let's look at changes required on server, RPC protocol, client.
*1. RPC protocol*
The client needs to know what the names and types of the additional columns. I
believe that
[TablesRequest|https://calcite.apache.org/avatica/docs/json_reference.html#tablesrequest]
yields a ResultSetResponse, and that response includes a list of column names
and types, so we're good.
The values of those columns need to come back. I believe we're also good.
*2. Client*
In the client, {{DatabaseMetaData.getTables}} will end up calling
{{RemoteMeta.getTables}}, and that calls {{toResultSet(MetaTable.class,
response)}}. Nowhere does the client create an instance of {{class MetaTable}}.
It just uses its fields to populate a {{ColumnMetaData.StructType}} that
contains a list of {{ColumnMetaData}}, one for each column. You can create some
additional {{ColumnMetaData}} instances, one for each extension column.
The values are returned in batches. Each batch is an instance of {{class
Frame}}, and contains {{List<Object> rows}}. You should investigate how those
row objects are created from the JSON result. If you're lucky they are
{{LinkedHashMap}} objects.
You'll need to use the right implementation of {{CursorFactory}} and that may
mean choosing the right style (ARRAY, LIST, MAP, ...).
*3. Server*
The server needs to generate the responses with the extra fields. It does not
necessarily do that from a list of {{MetaTable}} instances. (The server might
be implemented in C or Prolog, for all we know.)
{quote}Modifying the MetaTable class to include the hashmap of values{quote}
Minor quibble: the values will be in a {{java.util.Map}} but this will not
necessarily be a {{HashMap}}
> 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)
