[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741976#comment-17741976
]
Jeff Jirsa commented on CASSANDRA-18655:
----------------------------------------
Aleksey's comment here:
https://issues.apache.org/jira/browse/CASSANDRA-7622?focusedCommentId=16456572&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16456572
And my comment here:
https://issues.apache.org/jira/browse/CASSANDRA-7622?focusedCommentId=16456749&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16456749
In particular, this matches my memory, and the reason I spent 60 minutes of
NGCC talking about it: "We don't want it to be exposed in regular DDL. However,
we would like this to be at least a little bit generic, so that one could
plug-in extra virtual keyspaces on C* startup, similar to how some folks/forks
add extra system keyspaces and system tables. There are some use cases for
virtual tables that we want to experiment with (Jeff Jirsa gave a few examples
in his NGCC talk) that are compelling enough to at least allow this
possibility."
Sylvain agreed: "If by "plug-in", you mean "patch-in" (but easily so and
without being too limited), then sure, that's just good coding and no issue on
that from me."
The only written dissent I see is "I am also not convinced that we should do
it. I would really love to avoid another Trigger like feature.".
We're years in and adoption of vtables is high. I think it's clear this is not
a trigger like feature.
I would +1 a removal of `final`
> Unfinalise AbstractVirtualTable.select(..) for downstream patches
> -----------------------------------------------------------------
>
> Key: CASSANDRA-18655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18655
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
> Reporter: Michael Semb Wever
> Assignee: Michael Semb Wever
> Priority: Normal
>
> In AbstractVirtualTable the select methods are final. This prevents
> downstream C* engineers from implementing their own virtual tables where the
> select needs to be overridden.
> This is not a C* API and is not intended for C* users and operators.
> Extension of these methods should also clearly marked as experimental with no
> maintenance or compatibility provided from any release to another (including
> patch versions).
> The original proposal for Virtual Tables (CASSANDRA-7622) was to have a table
> "backed by an API, rather than data explicitly managed and stored as
> sstables". A number of people on the ticket supported the eventual idea of
> user-defined Virtual Tables. The consensus was that an incremental approach
> should be taken, where this should not be part of the initial implementation,
> and that use-cases and careful consideration around API security and
> compatibility would be needed.
> The next incremental approach can be to permit downstream patches to
> experiment against an explicitly labelled experimental (non-stable) internal
> code (so to protect the C* community from security and compatibility
> concerns). Such experiments will help smoke out and promote more grounded
> discussions for further work, if so found and desired.
> The patch is two lines: to remove the final keyword from both select(..)
> methods; and adding whatever comment/annotation we need to state their
> experimental/non-stable state and limited audience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
