[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320891#comment-15320891
]
Robert Stupp commented on CASSANDRA-7622:
-----------------------------------------
I'm with you, that sth like SHOW VARIABLES would be used from cqlsh. But the
node just added as the initial contact point. When that node fails, the
statement would be silently executed against another node. For SHOW VARIABLES
this is not super dramatic - but for an ALTER SYSTEM DECOMMISSION it is. That's
why I proposed {{WHERE node='1.2.3.4'}} as part of the syntax. At least, the
coordinator can check, whether it finds its own IP in the WHERE clause.
> 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)
