[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047253#comment-13047253
]
T Jake Luciani commented on CASSANDRA-2474:
-------------------------------------------
This is not so straight forward in the Hive case.
In order to provide the foo:bar approach you need to play tricks in the
HiveMetaStore since it will throw out that kind of table (it only knows about
foo). Brisk does have a HiveMetaStore impl that we could do this in but it's
separate from our hive driver. Meaning the two would need to assume they both
exist inorder to work at all... Users of the Hive driver shouldn't be forced to
only use it in brisk.
We could require Hive users create a table for each row but this is why I asked
initially about supporting many rows. In the MapReduce case this is the
norm... So I don't think the integration can be quite as seamless as you would
like.
My suggestion is to start with the hive support and see what subset we can
support in CQL rather than the other way.
> CQL support for compound columns
> --------------------------------
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Eric Evans
> Labels: cql
> Fix For: 1.0
>
>
> For the most part, this boils down to supporting the specification of
> compound column names (the CQL syntax is colon-delimted terms), and then
> teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
