Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 6 Jun 2016 09:21:41 +0000 (UTC)
From: "Benjamin Lerer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12729761.1406305663000.317.1465204901406@Atlassian.JIRA>
In-Reply-To: <JIRA.12729761.1406305663000@Atlassian.JIRA>
References: <JIRA.12729761.1406305663000@Atlassian.JIRA> <JIRA.12729761.1406305663566@arcas>
Subject: [jira] [Commented] (CASSANDRA-7622) Implement virtual tables
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 06 Jun 2016 09:21:43 -0000


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

Benjamin Lerer commented on CASSANDRA-7622:
-------------------------------------------

Thanks for the proposal. I think It would be nice to have one with more details. For example, some description of how it would be implemented for metrics will help.

For the moment, I do not see how the interface that you proposed can handle {{SELECT}} queries. What about: paging, restrictions, ordering, limit, ... We might not want to support everything but a minimum has to be supported. It might be worth to specify it. 

It will also be interesting to know what should be provided by Cassandra and what must be implemented by the virtual table provider.

From the syntax point of view I think that we should use {{CREATE VIRTUAL TABLE ...}}. It is clearer and it will allow us to handle it separatly in the ANTLR file. 

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