[CALCITE-5964] Support additional metadata attributes in GET_TABLES and GET_COLUMNS

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: avatica
• Labels: pull-request-available
• Assignee: Oliver Lee
• Reporter: Oliver Lee
• Created: 28/Aug/23 22:03
• Updated: 24/Oct/23 02:04

Description

The goal is for Avatica to be able to handle additional columns in the standard JDBC getTables() and getColumns() responses. 

After testing, it appears that the Avatica client in RemoteMeta is able to handle Signatures of different shapes that don't necessarily conform to the JDBC standard getTables.

I have opened a PR that adds a test to RemoteDriverMockTest that verifies that if a Signature comes in with additional columns, that Avatica is able to handle it fluently. 

 

This ticket is related to CALCITE-5982 , and includes some additions to connection properties to allow Calcite to create and send Signatures of different shapes. 

 

 

 

 

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 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:

1. Avatica user does not need to download new jar files if the server decides to send over new metadata data in the future
2. 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) 
3. Can handle attributes of varying types i.e. numberOne: int and booleanOne: boolean
4. 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

Issue Links

• is depended upon by: CALCITE-5982 Allow overloading the created enumerable in Calcite when calling getTables() or getColumns()
• links to: GitHub Pull Request #227