cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tupshin Harper (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7622) Implement virtual tables
Date Tue, 07 Jun 2016 21:35:21 GMT


Tupshin Harper commented on CASSANDRA-7622:

As the filer of this ticket, I largely agree about the scope issue. I was surprised to see
any notion of replication being discussed, because I didn't view persistence or cross-node
awareness/aggregation as being a feature of virtual tables.

I do think that exposing JMX provides the best initial use case, and would like to target
that first. The higher level interface that  Sylvain proposes is also very much in the right

That said, I disagree with one aspect. There's no reason to restrict the API to read only,
even initially. Most JMX metrics are read only, and those would either be ignore, or raise
an error, if they were attempted to be written to. But JMX metrix that arer settable, should
be exposable as r/w (with separate read vs write permissions, of course).

If an interface is designed sufficient to allow the elegant  reading and writing of jmx metrics,
it will be widely usable for many other plugins/virtual tables as well.

> Implement virtual tables
> ------------------------
>                 Key: CASSANDRA-7622
>                 URL:
>             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

View raw message