[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450066#comment-16450066
]
Chris Lohfink edited comment on CASSANDRA-7622 at 4/24/18 3:36 PM:
-------------------------------------------------------------------
I am fine with renaming virtualtable to systemview, its irrelevant at this
point and not exposed externally currently anyway. Ill do the rename in
followup if its important.
If you want it to display "SYSTEM VIEW" in cqlsh when do a describe, thats
purely a client side/driver change (if virtual or systemview whatever flag set,
use that instead of CREATE TABLE), you dont need to change CQL to do that.
There is a DDL change with this but its locked down internally and mostly just
for ease, I can take that out and require using the tablemetadata builder even
which might be a good idea. Changing protocol wont make that difference unless
your planning on a whole new place to store the schema and share that
information with driver/cqlsh. I think that can be captured in followup jira or
sub task to improve UX with cqlsh/drivers.
Its supposed to be able to do range queries and about any slice/dicing, but I
did miss short cutting the IN restriction, I'll fix that.
As for the schema... You have 1 cell per attribute of each metric? theres
currently 63 metrics with between 1 and 15 values - literally hundreds of cells
_per row_ which isnt viewable on a sane display. you can just as easily grab a
single value efficiently with impl:
{code}
SELECT one_min_rate FROM system_info.table_stats WHERE keyspace_name = 'system'
AND table_name = 'local' AND metric = 'writeLatency';
{code}
or see all parts of the metric:
{code}
SELECT * FROM system_info.table_stats WHERE keyspace_name = 'system' AND
table_name = 'local' AND metric= 'writeLatency';
{code}
If we want to fine tune the table_stats schema, we can just remove it from this
patch, and move to another patch to discuss that particular tables schema.
Thats not really what this ticket is about. There are a lot of tables to
create, lets just get the capability to create them in. If your implementation
is very similar with a ReadQuery replacement its at a high level the same
thing. In next patch I did refactor to look a bit cleaner and reuse existing
AbstractQueryPager logic more vs doing its own from scratch QueryPager.
was (Author: cnlwsu):
I am fine with renaming virtualtable to systemview, its irrelevant at this
point and not exposed externally currently anyway. Ill do the rename in
followup if its important.
If you want it to display "SYSTEM VIEW" in cqlsh when do a describe, thats
purely a client side/driver change (if virtual or systemview whatever flag set,
use that instead of CREATE TABLE), you dont need to change CQL to do that, and
changing protocol wont make that difference unless your planning on a whole new
place to store the schema and share that information with driver/cqlsh. I think
that can be captured in followup jira or sub task to improve UX with
cqlsh/drivers.
Its supposed range queries and about any slice/dicing, but I did miss short
cutting the IN restriction, I'll fix that.
As for the schema... You have 1 cell per attribute of each metric? theres
currently 63 metrics with between 1 and 15 values - literally hundreds of cells
_per row_ which isnt viewable on a sane display. you can just as easily grab a
single value efficiently with impl:
{code}
SELECT one_min_rate FROM system_info.table_stats WHERE keyspace_name = 'system'
AND table_name = 'local' AND metric = 'writeLatency';
{code}
or see all parts of the metric:
{code}
SELECT * FROM system_info.table_stats WHERE keyspace_name = 'system' AND
table_name = 'local' AND metric= 'writeLatency';
{code}
If we want to fine tune the table_stats schema, we can just remove it from this
patch, and move to another patch to discuss that particular tables schema.
Thats not really what this ticket is about. There are a lot of tables to
create, lets just get the capability to create them in. If your implementation
is very similar with a ReadQuery replacement its at a high level the same
thing. In next patch I did refactor to look a bit cleaner and reuse existing
AbstractQueryPager logic more vs doing its own from scratch QueryPager.
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Chris Lohfink
> Priority: Major
> Fix For: 4.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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
