[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315917#comment-15315917 ]
Jeff Jirsa commented on CASSANDRA-7622: --------------------------------------- Hey [~snazy], really appreciate any feedback. {quote} Don't get me wrong, I really like virtual tables, but I am not a fan of a {{CREATE TABLE}} for metrics - instead, I think it is better to provide predefined, virtual tables for what we have in a "virtual keyspace" like {{system_metrics}} or {{system_management}}. {quote} Totally agree that we should pre-define the tables we care about and will support/maintain in the tree, but even traditional system tables get created by {{CREATE TABLE}} throughout the code base - why would virtual be any different? We can still bake it in by default as we do with {{SchemaKeyspace}} and {{SystemDistributedKeyspace}}, but allowing arbitrary virtual table creation by {{CREATE TABLE}} also lets users create their own. {quote} Some administrative operations probably require additional CQL commands (e.g. {{ALTER SYSTEM DRAIN;}} ). {quote} What you're proposing makes sense, and seems reasonable, but also extends the DDL in ways that may not be necessary - we could alternatively use {{ALTER system_virtual.actions SET drain=true; }} and let whatever virtual table handler controls {{system_virtual.actions}} run drain and shut down, getting the same impact without extending the DDL? > 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)