[
https://issues.apache.org/jira/browse/CASSANDRA-18655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741878#comment-17741878
]
Michael Semb Wever edited comment on CASSANDRA-18655 at 7/11/23 7:27 AM:
-------------------------------------------------------------------------
bq. The final keyword in AbstractVirtualTable is to prevent people extending
that class to misuse it.
There's no misuse that wouldn't also exist when they implement VirtualTable
from scratch or just copy and patch AbstractVirtualTable themselves. In fact
the potential misuse is greater when AbstractVirtualTable is copied and hacked.
I would be in favour of removing both the final keywords and the VirtualTable
interface.
I'm all for defensive coding, and agree that the final keywords should have
been there to begin with. But also that a simple and informative request like
this warrants removing them.
It should be entirely valid to request the re-use of AbstractVirtualTable, the
imposition of code instability doesn't have to be via only the final keyword.
It's also easier to mark those two methods are non-stable (not an api) than a
whole interface.
bq. I do not recall such consensus.
I'm referring to what's written on 7622. AFAIK that's the only written record
we have. As I read it you were the only one adamant that Virtual Tables
should never evolve. The consensus that happened during the patch and review
process (in private conversations?) would have been bound to the patch, where
it was already agreed what the initial implementation should be limited to.
Numerous people entertain the idea of user defined virtual tables, what Brian
[refers|https://issues.apache.org/jira/browse/CASSANDRA-7622?focusedCommentId=15316875&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15316875]
to as (4). People also express their concern to the complexity of it. Such
an idea would definitely warrant a CEP, IMHO. Exploration and discussions on
potential use-cases is valid - providing as much context, concerns and
challenges into a richer discussion helps define the CEP.
This ticket is not about that discussion or CEP, it's not about such a "plug"
implementation that requires a formal API. Though this ticket is an impetus
to all that.
You know I always appreciate your inputs, but i'm having some trouble seeing
why this is a hard no from your perspective. Can you give me some more
background so we can address your concerns?
was (Author: michaelsembwever):
bq. The final keyword in AbstractVirtualTable is to prevent people extending
that class to misuse it.
There's no misuse that wouldn't also exist when they implement VirtualTable
from scratch or just copy and patch AbstractVirtualTable themselves. In fact
the potential misuse is greater when AbstractVirtualTable is copied and hacked.
I would be in favour of removing both the final keywords and the VirtualTable
interface.
I'm all for defensive coding, and agree that the final keywords should have
been there to begin with. But also that a simple and informative request like
this warrants removing them.
It should be entirely valid to request the re-use of AbstractVirtualTable, the
imposition of code instability doesn't have to be via only the final keyword.
It's also easier to mark those two methods are non-stable (not an api) than a
whole interface.
bq. I do not recall such consensus.
I'm referring to what's written on 7622. AFAIK that's the only written record
we have. As I read it you were the only one adamant that Virtual Tables
should never evolve. The consensus that happened during the patch and review
process (in private conversations?) would have been bound to the patch, where
it was already agreed what the initial implementation should be limited to.
Numerous people entertain the idea of user defined virtual tables, what Brian
[refers|https://issues.apache.org/jira/browse/CASSANDRA-7622?focusedCommentId=15316875&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15316875]
to as (4). People also express their concern to the complexity of it. Such
an idea would definitely warrant a CEP, IMHO. Exploration and discussions on
potential use-cases is valid - providing as much context, concerns and
challenges into a richer discussion discussion helps define the CEP.
This ticket is not about that discussion or CEP, it's not about such a "plug"
implementation that requires a formal API. Though this ticket is an impetus
to all that.
You know I always appreciate your inputs, but i'm having some trouble seeing
why this is a hard no from your perspective. Can you give me some more
background so we can address your concerns?
> 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
