[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org