You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Holman Lan (JIRA)" <ji...@apache.org> on 2016/09/01 00:58:20 UTC

[jira] [Commented] (DRILL-4420) C client and ODBC driver should move to using the new metadata methods provided by DRILL-4385

    [ https://issues.apache.org/jira/browse/DRILL-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453909#comment-15453909 ] 

Holman Lan commented on DRILL-4420:
-----------------------------------

Hello Laurent,

Below are the comments and questions we have from reading through the comment for Drill client C++ API changes (https://github.com/laurentgo/drill/commit/1f55a3e631cd97016b113b9d4bca07b5e016a25e). I apologize in advance for the poor formatting.

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.

    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? 

    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)



contrib/native/client/src/include/drill/fieldmeta.hpp

    Does m_bufferLength in FieldMetadata map to SQL_DESC_OCTET_LENGTH? (https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx)
Which field in FieldMetadata maps to SQL_DESC_LENGTH? (https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx)



contrib/native/client/src/include/drill/drillClient.hpp

    TableMetadata and ColumnMetadata does not return table comment/remarks. Could that be added?

    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)

    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.

    prepareQuery returns a query handle and executeQuery also returns a query handle. Are they the same handle? When should each of them get freed?
	
    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?

    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?

    For the vector of metadata objects passed in to the metadata listeners, are they valid until the corresponding query handle is freed?

Thanks,
Holman


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