[
https://issues.apache.org/jira/browse/DRILL-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15456634#comment-15456634
]
Laurent Goujon commented on DRILL-4420:
---------------------------------------
{quote}
Does m_bufferLength in FieldMetadata map to SQL_DESC_OCTET_LENGTH?
(https://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx)
In FieldMetadata, which field can we use to get the value for SQL_DESC_LENGTH
(which may be different then SQL_DESC_OCTET_LENGTH, especially for Unicode
characters)?
{quote}
{{getPrecision()}} would return the number of characters for a char field (it's
modeled after java {{ResultSetMetadata#getPrecision()}} method). As of now,
there's no getter for SQL_DESC_OCTET_LENGTH equivalent, but it's possible to
add one which would derive it from getPrecision().
Regarding {{m_bufferLength}}, it is the internal buffer size for the field
metadata (which might comprise several values) and not the maximum number of
bytes for this column.
{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)
{quote}
It's not populated for datetime types, but it should work DECIMAL data types
(you can check {{org.apache.drill.exec.store.ischema.Records.Column}} and
{{org.apache.drill.exec.work.metadata.MetadataProvider.ColumnProvider}})
{quote}
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}
Yes (same classes as above)
{quote}
There was a typo in one of the sentences in my previous comment. By "ODBC (and
JDBC) does not allow pattern for catalog function calls ..." I meant to say
"ODBC (and JDBC) does not allow pattern for catalog name restriction for the
catalog functions ...". Sorry about that. Would drill be able to treat catalog
name restriction as literal string? If this is a use case you are trying to
support or if you feel that this would make it inconsistent with the other
restrictions then not a problem, we will make sure to escape any reserved
characters before passing it in.
For getTables and getColumns in JDBC and SQLTables and SQLColumns, passing in
null for catalog name or schema pattern means the restrictions "should not be
used to narrow the search", whereas passing in an empty string for the two
restrictions has different meaning (tables that do not belong to a catalog or
schema). Since the getTables and getColumns Drill client API calls take a const
string reference for catalogPattern and schemaPattern, if we get null for the
two restrictions from the ODBC layer are we expected to just set % for the
restrictions? If that is the case then I guess that would be the justification
for keeping catalogPattern as pattern.
{quote}
Drill protocol uses patterns for each argument, so the JDBC or the ODBC driver
would have to escape properly when the argument it received from the user is
not pattern.
As for passing null/NULL to tell the server not to use the field to narrow the
search, it's exactly like you said: the same can be achieved with a "%" pattern
(with the benefit of having better guarantees against NULL values in C++ code)
> 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)
