[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16398815#comment-16398815
]
Chris Lohfink commented on CASSANDRA-7622:
------------------------------------------
1)
If they extend the inmemoryvirtualtable it handles {{LIMIT}}, {{PER PARTITION
LIMIT}} , {{GROUP BY}}, {{DISTINCT}} etc (ie all the system_info tables). With
it the methods an implementor handles is:
{code}
public void mutate(DecoratedKey partitionKey, Row row)
public void read(StatementRestrictions restrictions, QueryOptions options,
ResultBuilder result)
{code}
ie the compactionstats
{code}
public void read(StatementRestrictions restrictions, QueryOptions options,
ResultBuilder result)
{
UUID hostId = StorageService.instance.getLocalHostUUID();
for (Map<String, String> c :
CompactionManager.instance.getCompactions())
{
result.row(hostId, UUID.fromString(c.get("compactionId")))
.column(TASK_TYPE, c.get("taskType"))
.column(KEYSPACE_NAME, c.get("keyspace"))
.column(TABLE_NAME, c.get("columnFamily"))
.column(BYTES_COMPACTED, c.get("completed"))
.column(BYTES_TOTAL, c.get("total"))
.endRow();
}
}
{code}
Which provides a builder interface to generate the resultset.
An implementation of VirtualTable and writing own ReadQuery will only be needed
or do something more efficient over large datasets or in distributed fashion. I
dont expect anyone to do that, the interface just works at that level of the
query best otherwise the patch would have too be a rewrite the entire
columfamilystore with all its implications.
2,3) Ill start working on more tests
4) fixed
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> 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
