[ 
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740954#comment-17740954
 ] 

Benjamin Lerer commented on CASSANDRA-18655:
--------------------------------------------

If people wish to create their own VirtualTable implementation they can simply 
extend the {{VirtualTable}} interface. The {{final}} keyword in 
{{AbstractVirtualTable}} is to prevent people extending that class to misuse 
it. 

??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.??

I do not recall such consensus. On the other hand I recall long discussions 
that blocked the ticket for around 2 years. In the end the choice was made to 
use Virtual tables only for exposing local node internal information and that 
is what the current implementation support.  

> 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

Reply via email to