[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478230#comment-16478230
]
Aleksey Yeschenko commented on CASSANDRA-7622:
----------------------------------------------
[~blerer] thanks.
I took [~cnlwsu]'s and [~jjirsa]'s original patch as the base, read path
integration from [~blerer]'s, almost as is, and rewrote the bits that I wasn't
happy with in either patch - namely schema and metadata handling and write path
integration.
The end result, ready for review, is
[here|https://github.com/iamaleksey/cassandra/commits/7622-4.0] - without any
system views in it. And
[here|https://github.com/iamaleksey/cassandra/commits/7622-4.0-more] lives
another commit, with extracted sample system views by [~cnlwsu] - compaction
stats, settings, and ring state - included as further example of the interface.
I would prefer if we reviewed and committed them as separate tickets, one JIRA
per table, and everything else we might want to provide, such as metrics,
connected clients, size estimates, etc.
Some notes:
1. I did go with the name 'virtual table' and 'virtual keyspace' for internal
classes and methods, but with 'system_views' for the name of the keyspace where
the initial system views will live. I'm using 'virtual table/virtual keyspace'
internally because the concept itself is more generic than just system views,
and we will provide other virtual keyspaces and tables that don't quite fit
'system view' definition. Class renames that went with it were the only change
to [~blerer]'s read path integration code, otherwise it was taken as is (read
command / read query changes).
2. Virtual tables can now only live in virtual keyspaces, and cannot be mixed
with regular tables. Their metadata is also kept separately from {{Schema}},
and {{Keyspace}} / {{ColumnFamilyStore}} classes have been left essentially
untouched.
3. Schema of virtual keyspaces and tables itself is now exposed by
{{system_virtual_schema}} keyspace tables, that are themselves virtual. This
simplifies the evolution of virtual keyspaces/tables implementations, as
changing schema of the tables, dropping and adding new ones, becomes
essentially hassle free - there is nothing to clean up or migrate, only what
is, is. If and when we eventually decide to expose creation of virtual
keyspaces via DDL, the way I see it, we'd create a {{CREATE VIRTUAL KEYSPACE ..
WITH <class>}} statement, and persist keyspace name / implementation class name
in something like {{system_schema.virtual_keyspaces}} table.
4. Write path integration was rewritten to terminate at statement / mutation
collector levels, with a new specialised {{VirtualMutation}} class to round it
up. The end result is not having to special-cases any code in {{Keyspace}} or
{{StorageProxy}} or {{CassandraKeyspaceWriteHandler}} or {{Mutation}}, which in
my opinion is cleaner than what we had in either of the two combined patches.
5. {{MapBasedSystemView}} from [~blerer]'s patch was roughly translated into
{{AbstractVirtualTable}} that is a bit more generic.
[~cnlwsu] and [~blerer], can you please have a look at the proposed combined
patch, and let me know if you have any concerns or objections, or see any
problems with it? Once those are addressed, I would like to commit the
interface patch, and have [~cnlwsu] move on to implementing the actual system
views we want to expose, in separate tickets. Thanks (:
> 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.0
>
> Attachments: screenshot-1.png
>
>
> 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
