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

Chris Lohfink commented on CASSANDRA-7622:
------------------------------------------

You do not get {{CREATE TABLE USING CompactionStats compaction_stats}}, it 
still displays the schema how you would expect with a {{create table....}} 
output because thats the way cqlsh is created to take a schema and display it. 
This ticket does not add pluggable storage, it creates a system_info keyspace 
that has some pre-created (with more to come if it ever gets through) tables 
displaying internal information, like compaction stats, table metrics (all of 
them), all configuration settings (with some settable), and ring state. It 
makes it (hopefully) easy to make more of these as well with any kind of 
querying you want (normal cql query limitations do not apply, with exception of 
some of the order by ones). 

This patch creates a shim that sits between the parsing of the query and 
actually executing it. The only implementation is that shim is one for this 
system_info. While I think its possible to use that shim to do other things I 
very much doubt it would ever be used as such.

> Implement virtual tables
> ------------------------
>
>                 Key: CASSANDRA-7622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Tupshin Harper
>            Assignee: Chris Lohfink
>            Priority: Major
>             Fix For: 4.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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to