cassandra-commits mailing list archives

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

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

Tupshin Harper commented on CASSANDRA-7622:
-------------------------------------------

An additional thought is that the capabilities framework (CASSANDRA-8303) could be used to
to restrict the available commands that would make it through to the virtual table implementation.

A possibly controversial example of this would be to only support UPDATE operations and not
INSERT operations to semantically denote the fact that this table doesn't support adding new
hosts, metrics, or attributes, but does support updating them. This wouldn't restrict all
unsupported behavior, and the table implementation would still have to return errors if a
read-only (or non-existent) attribute were updated, but it seems a bit cleaner than having
the table claim to support INSERTs.

A (maybe) less controversial use of 8303 would be to disallow all write operations (both UPDATE
and INSERT as well as others) for tables that are truly read-only.

And in the JMX case, it would certainly make sense to have different users have either SELECT
only permissions or SELECT and UPDATE.



> 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