[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539801#comment-14539801
]
Benjamin Lerer commented on CASSANDRA-7622:
-------------------------------------------
Before proposing anything, I think that we should clarify the requirements.
So let's start the ball rolling.
The expression "virtual tables" implies that they will just be a different type
of tables.
Which implies that we should be able to perform all the type of queries that we
perform on a normal table onto a virtual table.
The problem that I see with this is that the 2 use cases discussed in the
description have a different scope than the one of a normal table. The data of
a normal table are distributed whereas the configuration properties or the JMX
variables are not.
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.
> 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)
