[
https://issues.apache.org/jira/browse/HBASE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840689#comment-13840689
]
Nick Dimiduk commented on HBASE-10091:
--------------------------------------
Such a parser should probably allow registering aliases for a more complete
type definition in order to make interactive experiences (such as HBASE-10071)
more palatable. Once could establish an alias for the session, say {{long =>
OrderedInt64#DESCENDING}}, {{decimal => OrderedNumeric}}, and {{my_struct =>
some composite Struct declaration}}.
> Exposing HBase DataTypes to non-Java interfaces
> -----------------------------------------------
>
> Key: HBASE-10091
> URL: https://issues.apache.org/jira/browse/HBASE-10091
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Nick Dimiduk
>
> Access to the DataType implementations introduced in HBASE-8693 is currently
> limited to consumers of the Java API. It is not easy to specify a data type
> in non-Java environments, such as the HBase shell, REST or Thrift Gateways,
> command-line arguments to our utility MapReduce jobs, or in integration
> points such as a (hypothetical extension to) Hive's HBaseStorageHandler. See
> examples where this limitation impedes in HBASE-8593 and HBASE-10071.
> I propose the implementation of a type definition DSL, similar to the
> language defined for Filters in HBASE-4176. By implementing this in core
> HBase, it can be reused in all of the situations described previously. The
> parser for this DSL must support arbitrary type extensions, just as the
> Filter parser allows for new Filter types to be registered at runtime.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
