[
https://issues.apache.org/jira/browse/DRILL-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15454280#comment-15454280
]
Laurent Goujon commented on DRILL-4420:
---------------------------------------
{quote}
In contrib/native/client/src/clientlib/fieldmeta.cpp
There seems to be support for signed and unsigned variants for TINYINT,
SMALLINT, INTEGER and BIGINT but the type name between the two variants are the
same. Having the same type name for signed and unsigned variants might be
ambiguous in the query where type name is expected such as CREATE TABLE
statements or in the CAST function.
{quote}
The support has always been there, just not exposed directly by the C++
connector, and it is(was?) up to the library user (like the ODBC driver) to do
the mapping between the minor type and the SQL type. I don't know what mapping
the ODBC driver is currently using (it should be possible to figure out that)
but it might be different from the one I added to the C++ API (which is the
same as the one in the Java code, and used by the JDBC driver).
Regarding CREATE TABLE and CAST function, since they operates on SQL types (and
not the Drill internal types) anyway, it would be up to the server to decide
how to enforce them, and I don't think this mapping would change anything to it.
{quote}
Drill client exposes UNKNOWN_SEARCHABILITY, NONE, CHAR, NUMBER and ALL and ODBC
exposes SQL_PRED_NONE, SQL_PRED_CHAR, SQL_PRED_BASIC, SQL_PRED_SEARCHABLE. It
seems like NONE maps SQL_PRED_NONE, CHAR maps to SQL_PRED_CHAR, and ALL maps to
SQL_PRED_SEARCHABLE, is that correct? Does NUMBER map to SQL_PRED_BASIC? What
is the expectation for UNKNOWN_SEARCHABILITY?
{quote}
I assume it is correct according to the protobuf comments. For
{{UNKNOWN_SEARCHABILITY}}, it means that the server was not able to determine
this information, and it's up to the driver to decide which policy to apply I
guess.
{quote}
Would there be support for SQL_DESC_BASE_COLUMN_NAME, SQL_DESC_BASE_TABLE_NAME,
SQL_DESC_NUM_PREC_RADIX and SQL_DESC_UNNAMED in FieldMetadata?
(https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx)
{quote}
I think the support is already here for some of them (respectively the
{{getName()}} and {{getTableName()}} methods). For the radix, we would have to
add it to the RPC layer, but it should be okay. As for {{SQL_DESC_UNNAMED}}, we
could have a boolean field to be set if none of the name and the alias are not
set (there's no equivalent in JDBC world)
{quote}
Does m_bufferLength in FieldMetadata map to SQL_DESC_OCTET_LENGTH?
(https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx)
{quote}
It should, but I would need to confirm.
{quote}
TableMetadata and ColumnMetadata does not return table comment/remarks. Could
that be added?
{quote}
Certainly, although Drill might not be able to return this information as of
now (this is not part of the RPC layer for sure, and it might also require this
information to be extracted by the server).
{quote}
Can the value returned by ColumnMetadata.getNumericScale() be used to derive
the value for DECIMAL_DIGITS for TIME, TIMESTAMP and DECIMAL data types?
(https://msdn.microsoft.com/en-us/library/ms711683(v=vs.85).aspx)
Can the value returned by ColumnMetadata.getIntervalType () be used to derive
the value for SQL_DATETIME_SUB?
(https://msdn.microsoft.com/en-us/library/ms711683(v=vs.85).aspx)
{quote}
Let me check
{quote}
ODBC (and JDBC) does not allow pattern for catalog function calls but the
getCatalogs, getSchemas, getTables and getColumns API calls in Drill client
expects a catalog pattern, are reserved characters expected to be escaped?
What type of pattern is being used for catalogPattern, schemaPattern,
tablePattern and columnPattern? Regex or the type of patterns described in
(https://msdn.microsoft.com/en-us/library/ms710171(v=vs.85).aspx)? We notice
the comment mentioned “LIKE expressions” so we suspect it treated more like the
way specified in the link, but would just like to confirm.
{quote}
JDBC allows patterns for some of its metadata methods. See
https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html for
reference, but when an argument ends with Pattern, it means it accepts a SQL
{{LIKE}} pattern (which uses the special characters % and _).
ODBC seems to also allow patterns in its catalog functions according to
https://msdn.microsoft.com/en-us/library/ms716447(v=vs.85).aspx
As for the C++ connector, patterns are also SQL {{LIKE}} patterns, with {{_}}
the escape character.
{quote}
prepareQuery returns a query handle and executeQuery also returns a query
handle. Are they the same handle? When should each of them get freed?
{quote}
those would be two different handles, the one returned by {{executeQuery}}
being released when you're done with the query (similar to {{submitQuery}}),
and the one returned by {{prepareQuery}} to be released when you're done with
the prepared statement (after that, the prepared statement pointer would be
invalid).
{quote}
What is the life cycle of Metadata? Is it expected to be instantiated at the
beginning of a connection, used throughout the connection and freed at the end
of the connection?
{quote}
the lifecycle of Metadata is linked to the lifecycle of the connection, but you
could call the {{getMetadata}}/{{freeMetadata}} at any time, as many times as
you need.
{quote}
Are the metadata listeners (pfnCatalogMetadataListener,
pfnSchemaMetadataListener, pfnTableMetadataListener and
pfnColumnMetadataListener) expected to be called only once for each call to
getCatalogs, getSchemas, getTables and getColumns? If it’s called multiple
times, how does the drill client signal the end of the result set has been
reached, by passing a vector of the corresponding metadata object of size 0 to
the listener?
{quote}
As the RPC layer returns all results at once, those listeners would only be
called once.
{quote}
For the vector of metadata objects passed in to the metadata listeners, are
they valid until the corresponding query handle is freed?
{quote}
I expect so (I haven't complemented the implementation yet).
> C client and ODBC driver should move to using the new metadata methods
> provided by DRILL-4385
> ---------------------------------------------------------------------------------------------
>
> Key: DRILL-4420
> URL: https://issues.apache.org/jira/browse/DRILL-4420
> Project: Apache Drill
> Issue Type: Sub-task
> Reporter: Jacques Nadeau
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
