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

Tupshin Harper commented on CASSANDRA-7622:
-------------------------------------------

As the filer of this ticket, I largely agree about the scope issue. I was 
surprised to see any notion of replication being discussed, because I didn't 
view persistence or cross-node awareness/aggregation as being a feature of 
virtual tables.

I do think that exposing JMX provides the best initial use case, and would like 
to target that first. The higher level interface that  Sylvain proposes is also 
very much in the right direction. 

That said, I disagree with one aspect. There's no reason to restrict the API to 
read only, even initially. Most JMX metrics are read only, and those would 
either be ignore, or raise an error, if they were attempted to be written to. 
But JMX metrix that arer settable, should be exposable as r/w (with separate 
read vs write permissions, of course).

If an interface is designed sufficient to allow the elegant  reading and 
writing of jmx metrics, it will be widely usable for many other plugins/virtual 
tables as well.

> 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)

Reply via email to