cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7622) Implement virtual tables
Date Tue, 12 May 2015 13:22:00 GMT

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

Mime
View raw message