[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539815#comment-14539815
]
Aleksey Yeschenko commented on CASSANDRA-7622:
----------------------------------------------
Virtual tables don't have to support all types of queries. The interface should
have a method that specifies what a table supports and what it doesn't support.
Some table won't be writable, for example. Some might not support some of the
SELECT queries. None of them should support being mixed in a batch statement.
I think it makes sense to not allow virtual and non-virtual tables in the same
keyspace, too. We might want to have a special virtual keyspace to all of the
virtual tables, or allow multiple such virtual keyspaces. In which case it
probably makes sense to define the interface at the virtual keyspace level.
bq. So the first question is: Should we assume that a virtual table will always
be bound to the current node? Meaning that you will only get the data of the
node that process the request. The other option being that you can query any
node for the data of any other node.
This should be left up to the particular virtual table interface implementation
to decide. {{SelectStatement}}, or a new special form of it, would call methods
directly on the instance of the virtual keyspace or virtual table object.
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Tupshin Harper
> Assignee: Benjamin Lerer
> 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)
