cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremiah Jordan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7622) Implement virtual tables
Date Mon, 06 Jun 2016 17:56:21 GMT

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

Jeremiah Jordan commented on CASSANDRA-7622:
--------------------------------------------

The issue I see is that the "replication" of virtual tables is tied to the implementation
class.  So you have to be very careful about the replication of the keyspace you put the table
in.

Things I would want to do with virtual tables:
Should apply to the node the query is run on, or be able to specify the node:
1. Get/Set current configuration values
2. Get metrics
3. Pretty much anything we currently expose in JMX

For those three things I would either want queries to be local to the current node, or have
the routing based on the IP someone queried.  Like "node" would be the PK and when someone
queries for select * from config_table;"

Could be node local or not, completely depends on what you are doing:
1. Run application code to do something.  Stuff I would do here would probably be similar
to things one might do in UDF/UDA but you would have inherently lower level/more access to
the rest of C* as you wouldn't be confined by the security models those impose.

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

Mime
View raw message