cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From " Brian Hess (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7622) Implement virtual tables
Date Wed, 08 Jun 2016 16:52:21 GMT

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

 Brian Hess commented on CASSANDRA-7622:
----------------------------------------

I think this is a bit narrow of thinking. I can see many use cases for programmatic access
to these values. If SHOW VARIABLE is useful in cqlsh it could have special cqlsh commands
that convert into this. 
If you want to mix regular CQL and these, you'd need different Sessions as you'd need separate
Cluster objects (so you can have a WhiteListPolicy for the one node of interest). Or if you
want to look at the metrics for multiple nodes you would need one Cluster object per node.
 

> Implement virtual tables
> ------------------------
>
>                 Key: CASSANDRA-7622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Tupshin Harper
>            Assignee: Jeff Jirsa
>             Fix For: 3.x
>
>
> There are a variety of reasons to want virtual tables, which would be any table that
would be backed by an API, rather than data explicitly managed and stored as sstables.
> One possible use case would be to expose JMX data through CQL as a resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml configuration
information. So it would be an alternate approach to CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not presupposing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message