[ 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