[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450066#comment-16450066 ]
Chris Lohfink commented on CASSANDRA-7622: ------------------------------------------ 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