[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456198#comment-16456198
]
Sylvain Lebresne commented on CASSANDRA-7622:
---------------------------------------------
Fwiw, I do think it would be worth separating the discussion on the {{system
view}}/{{virtual table}} mechanism from the one on the exact schema of metrics
tables for the sake of focus. Surel
y we can find 1 or 2 simple (yet useful to have) tables/views with
uncontroversial schema to start with.
Because I do think there is enough discussion to be had on the mechanism itself
(both on how it is exposed to user in general, and on the implementation in
particular).
For instance, I do have a major high level concerns on the current patch in
that I am *strongly* in favor of not shipping syntax for creating virtual
tables, at least for the initial commit. I am completely sold on virtual tables
as a mean to expose configuration infos and metrics, but I'm a lot less sold
about letting user create their own.
_At the very least_, the latter adds a lot of risk and difficulties:
* we're more or less committing to an API which could limit us moving forward,
so we need to be a bit careful
* there is security/foot-shooting risks. How do we mitigate them?
* It increase the test and documentation surface area quite a bit (assuming we
care about testing/documenting things right).
* We have more stuff to discuss from the get go (creation syntax for instance;
If we were to do this, then I'm definitively not a fan of not providing the
schema at all in the {{CREATE}} for instance).
Adding to that the usual question we should always ask of "are we not feature
creeping?".
All this to say that we should discuss the compelling use cases that makes
adding user creation worth it. I haven't seen that yet. And more generally, I
see no reason for not moving that as a 2nd step. Surely everyone agrees doing
things incrementally is better, and there is a very clear and logical path for
being incremental here.
And so I'm strongly in favor for the first version of this to be 98%[1]
transparent for end users: it should look like the addition of a bunch of new
system tables, but how those tables are implemented underneath should be
largely an implementation detail.
I can make the additional high level comments:
* I'd really rather not have the mechanism tied to a particular keyspace. If
keyspaces are added out of this, this should be because they make sense
"organization"-wise. That is, I could see use adding {{system_configurations}}
and {{system_metrics}} keyspaces, less fan of a
{{system_view}}/{{virtual_tables}} one.
* The patch seems to disable the {{ALLOW FILTERING}} check for virtual tables.
I'm conflicted on this. On the one side, I understand it's technically safe
(because served from memory and we know it will never grow big enough to be an
issue anyway), but on the other side I wonder if creating an inconsistency API
wise won't confuse users more than anything, especially when {{ALLOW
FILTERING}} is probably not something that well understood in the first place.
Part of me would prefer that we explain {{ALLOW FILTERING}} better and keep
things consistent.
[1]: the 2% remaining is that: 1) we should probably at least add a flag in the
schema of those tables for future proofing and 2) those tables won't have
sstables on disk, so we cannot entirely hide the fact those tables have a
different implementation.
bq. I am fine with renaming virtualtable to systemview, its irrelevant at this
point and not exposed externally currently anyway. Ill do the rename in
followup if its important.
I wouldn't dismiss that discussion as unimportant (it's ok to not have much
personal opinion of course), because naming is important and even if that name
doesn't appear in any user visible string (not true in you patch btw), we'll
likely use it in doc and discussions. And we have a really bad track record of
confusing users with inconsistent or changing naming so let's learn and
improve, not repeat our mistakes.
Anyway, on the one side I think [~blerer] argument that system views is
somewhat of a standard is compelling (provided what we do here is indeed close
to what those other DB do). But on the other side, I can come up with the
following counter-arguments:
* if we do ever allow user to create their own, then "System View" becomes imo
somewhat misleading/wrong. As said above, I'm actually yet to be convinced that
we should do the former, but not to the point that I'm against future proofing.
* we've used "virtual tables" for a long time now. I worry that it's too late
to change the naming now, that even if we somewhat officially decide to rename
to System Views, people will informally continue to refer to "virtual tables"
and more confusion than anything will follow.
As said above, I'm in favor of making this as transparent for users as possible
and by and large to treat the new tables are largely just some more system
tables, so I think I have a preference for sticking to "virtual".
> 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.x
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
