drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristine Hahn (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DRILL-3134) Doc: "Supported ... Types" section doesn't include complex types
Date Thu, 28 May 2015 00:50:18 GMT

     [ https://issues.apache.org/jira/browse/DRILL-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristine Hahn resolved DRILL-3134.
    Resolution: Fixed

Thanks for the info, guys. Fixed. http://drill.apache.org/docs/supported-data-types/#composite-types

> Doc:  "Supported ... Types" section doesn't include complex types
> -----------------------------------------------------------------
>                 Key: DRILL-3134
>                 URL: https://issues.apache.org/jira/browse/DRILL-3134
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Daniel Barclay (Drill)
>            Assignee: Kristine Hahn
> On the the "Supported Data Types" page at http://drill.apache.org/docs/supported-data-types/,
the first subsection (before the "Casting and Converting Data Types" subsection) doesn't include
composite types (arrays and maps).  Since that subsection seems to be intended to be the orientation
to the set of data types that are available in Drill, it should include composite types as
well as the atomic types it already includes.
> For those composite types, it should mention the key type-specific operations on those
types (i.e., for arrays: array element references (SQL's <array element reference> construct,
e.g., {{a[1]}}); for maps: the construct(s) that Drill provides for referring to the value
for a given key, e.g., {{m['k']}}).  (It should probably also have links to the sections,
pages, or subsections for the special functions for those types (e.g., KVGEN, FLATTEN).)
> (Note that although the text "SQL data types for query input" seems (depending the interpretation
of "query input") to indicate that the section was conceived of to document the set of data
types for which users can _give literal values_ in SQL queries, that apparent intent should
be widened to the set of data types that users _deal with_ in queries.  
> For example, even though users can't (yet) give a value of an array type in a query,
they can deal with array values coming from data sources, e.g., by indexing the array value
to get a specific element of each array value.)

This message was sent by Atlassian JIRA

View raw message