[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315709#comment-15315709 ]
Jeff Jirsa commented on CASSANDRA-7622: --------------------------------------- Proposing: {code} CREATE TABLE USING 'o.a.c.db.virtual.ClassName' [IF NOT EXISTS] ks.cfName ( column text, column2 int, etc ) WITH virtual_table_options = {'key':'value', 'key2':'value2'} {code} Implication here is that K_USING already exists in the grammar (e.g. custom indexes), and it's fairly consistent for users. Presence of {{USING class}} would sets a {{VIRTUAL}} flag for the CFMetaData. Instantiate the specified class passing the CFMetadata and key/value map, store the resulting instance somewhere (map within Schema?). Columns would still be defined in the standard way, persisted to the normal schema tables so drivers / cqlsh wouldn't need to be modified. At minimum, the virtual tables should implement: {code} public String class(); public Map<String,String> options(); public String keyspace(); public String tableName(); public boolean writable(); public void execute(PartitionUpdate update, Clustering clustering, UpdateParameters params) throws InvalidRequestException; public boolean readable(); public ResultMessage.Rows execute(QueryState state, QueryOptions options) throws RequestExecutionException, RequestValidationException; {code} Then, in {{SelectStatement}} if the CFMetadata isVirtual and {{readable()}}, pass state/options from {{SelectStatement.execute}} through to the virtual table's version. Similarly, in {{UpdateStatement}}, if CFMetadata isVirtual for any updated rows and {{writable()}}, pass partitionKey + params from {{UpdataStatement.execute}} through to the virtual table's version. The virtual tables I'm specifically interested in: - JMX getters and setters, probably implemented as multiple smaller virtual tables: -- Ring state / equivalent of {{nodetool gossipinfo}} / {{o.a.c.net FailureDetector}} -- CF attributes / equivalent of {{o.a.c.db ColumnFamilies.keyspace.table CompactionParametersJson}} and similar -- JMX {{o.a.c.metrics}} - YAML config getters and setters a la CASSANDRA-9233 - SSTableMetadata virtual table (list all sstables per CF, showing timestamps / repairedAt, ponies may with UPDATE .. SET deleted=true to mark a table obsolete) Feedback appreciated on all of this, but especially: - The two meaty {{execute}} functions here provide a lot of flexibility, but also a lot of rope - is it too much rope? - On {{ALTER}} table: we could simply replace the instance in the map, or do we disallow ALTER (and instead require DROP + CREATE)? > 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)