[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923709#comment-16923709
]
Sylvain Lebresne commented on CASSANDRA-14825:
----------------------------------------------
bq. but is there any reason why we can't also offer a virtual table solution?
That would mean supporting 2 different ways to do the exact same things. That's
usually not considered ideal.
bq. as it allows users to access schema via any driver, and doesn't depend on
the drivers to build schema
I think you misunderstood [~snazy]'s comment above. He's not saying we should
stick to cqlsh-based {{DESCRIBE}}, he's mentioning the alternative to the
virtual table approach of having {{DESCRIBE}} being a genuine CQL (server-side)
command, one that would return result sets (and that I describe in a number of
comments above).
This would still give users access to the schema via any driver (without any
driver change) and would not depend on the drivers to build schema.
And fwiw, I so far continue to believe that this server-side {{DESCRIBE}}
approach is, as objectively as I can put it, better than a virtual-table one.
As I've mentioned before, users already know {{DESCRIBE}} and as {{DESCRIBE}}
is not going away cqlsh-side, the virtual table approach kind of creates 2
separate ways to "describe" schema for users, which again don't feel ideal to
me.
Additionally, and that's the point [~snazy] mentioned, using a specific command
(instead of basically reusing {{SELECT}}) gives us flexibility for schema
specific stuffs much more easily. As Robert says, there is subtleties when it
comes to schema, in particular some things that are kind of "internal" (dropped
columns record, table ID, ...), but can be necessary when needing to recreate
the schema identically. So there is a (genuine afaict) need for both getting
the schema with and without those internal info (something we currently support
badly, but it's not a reason to continue doing so).
With the {{DESCRIBE}} approach, this is simple, just support some {{WITH
INTERNALS}} to decide if those "internals" are returned or not. With the
virtual table approach, not so much. Adding syntax to {{SELECT}} that is only
ever useful when querying a handful of system views is ugly.
As for the argument that virtual tables give you the "full power of SELECT", I
think it's more theoretical than anything when you look into the details. It's
not like SELECT is _that_ flexible in the first place, it's somewhat limited by
what schema we pick for the system view. And the {{DESCRIBE}} syntax already
provides 1) full schema, 2) schema of one keyspace and 3) schema of one
"object" for all our schema objects (table, types, ...). What more do we need
in practice?
> Expose table schema for drivers
> -------------------------------
>
> Key: CASSANDRA-14825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14825
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Reporter: Chris Lohfink
> Assignee: Chris Lohfink
> Priority: Normal
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently the drivers recreate the CQL for the tables by putting together the
> system table values. This is very difficult to keep up to date and buggy
> enough that its only even supported in Java and Python drivers. Cassandra
> already has some limited output available for snapshots that we could provide
> in a virtual table or new query that the drivers can fetch. This can greatly
> reduce the complexity of drivers while also reducing bugs like
> CASSANDRA-14822 as the underlying schema and properties change.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
