[
https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924088#comment-16924088
]
Robert Stupp commented on CASSANDRA-14825:
------------------------------------------
The implementation in the (Python) driver used by {{cqlsh}} is full of details
of database version specifics. Therefore, the reason to move the {{DESCRIBE}}
functionality to the server-side is absolutely fine. I think, there's consensus.
{{DESCRIBE}} is a well known command in {{cqlsh}}, so something that C* users
know for many years now.
But {{DESCRIBE}} is also a pretty complex implementation that is not that easy
to map to a {{SELECT}}, especially considering exposing database internals that
are necessary for backup/restore use cases. My point here is: it's much easier
to extend the syntax of {{DESCRIBE}} to make it more user friendly than to add
new things via system views. In other words: {{DESCRIBE}} is much more flexible
IMO.
A server side {{DESCRIBE}} doesn't need any protocol changes, it would be
implemented like {{LIST ROLES}} is - i.e. returning a result set with a single
column of type {{text}}. All that users of {{DESCRIBE}} would have to do is to
concatenate the strings from all rows to get a DDL script. Paging is pretty
important in the context of {{DESCRIBE}}, as some people have a ton of tables
in a single keyspace, so the DDL to describe a single keyspace can become quite
big. Even the {{DESCRIBE}} of a single table can become big - some MVs here, a
lot of UDTs there (it shouldn't, yes, but bad data models exist). Thing of a
{{DESCRIBE SCHEMA}} over 200 keyspace with 100 tables in each using 100 UDTs -
it's insane and probably doesn't exist in the wild, but thanks to the schema
code improvements (already committed and future ones), this might become more
and more frequent.
Having two things that do (nearly) the same thing is confusing IMO.
> 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
