[
https://issues.apache.org/jira/browse/CALCITE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739224#comment-17739224
]
Julian Hyde commented on CALCITE-521:
-------------------------------------
I am undecided how to implement this. To date we have added a new request for
each metadata request (e.g. we added
[Service.TablesRequest|https://calcite.apache.org/avatica/javadocAggregate/org/apache/calcite/avatica/remote/Service.TablesRequest.html]
for
[getTables|https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A-]).
That requires a lot of new requests.
An alternative would be to translate each request to a query. For example
{{getTables(null, null, "EMP", null)}} becomes a query request with the query
{code}
SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE 'EMP'
{code}
This would mean fewer requests, but the client would need more knowledge. It
would need to know the name of the information schema table, and how each
parameter maps to a column name. Note that some parameters are strings, some
act as patterns (e.g. allowing '%'), in some of them a value of 'null' means
'no restriction', and in some of them a value of "" means 'retrieve records
whose value is null'.
And of course the server would need to provide the information schema tables.
That's not difficult to do, but might be difficult to do efficiently, because
the information schema might be a union over many catalogs and databases, and
an efficient implementation should use the {{catalog}} and {{schemaPattern}}
parameters to avoid forming the whole union.
> Implement metadata requests in remote JDBC driver
> -------------------------------------------------
>
> Key: CALCITE-521
> URL: https://issues.apache.org/jira/browse/CALCITE-521
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Julian Hyde
> Assignee: TJ Banghart
> Priority: Major
>
> The remote JDBC driver supports getCatalogs() and getSchemas(), via requests
> CatalogsRequest and SchemasRequest. We need to implement more methods:
> * getTables
> * getColumns
> * getTableTypes
> * getProcedures
> * getProcedureColumns
> * getColumnPrivileges
> * getTablePrivileges
> * getBestRowIdentifier
> * getVersionColumns
> * getPrimaryKeys
> * getImportedKeys
> * getExportedKeys
> * getCrossReference
> * getTypeInfo
> * getIndexInfo
> * getUDTs
> * getSuperTypes
> * getSuperTables
> * getAttributes
> * getClientInfoProperties
> * getFunctions
> * getFunctionColumns
> * getPseudoColumns
> Many of these will return empty sets when run against Calcite, because
> Calcite doesn't override the MetaImpl, and the default implementation returns
> empty. That's OK. This task is just to create the plumbing from client to
> server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
