[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14605827#comment-14605827
]
Adam Holmberg commented on CASSANDRA-8005:
------------------------------------------
Revisiting this ticket as we look again at CASSANDRA-6717. We're now faced with
supporting multiple metadata implementations, *and* generating CQL from them. I
totally agree that toString is a misfeature on the client side, which is why I
am strongly in support of this ticket.
I think people expect to be able to DESC and reproduce schema in CQL,
independent of the metadata implementation. In the past CQL output has been
implemented in the driver. If the driver does not provide this, how would we
reproduce the schema? I think that is the job of the server.
> Server-side DESCRIBE
> --------------------
>
> Key: CASSANDRA-8005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Tyler Hobbs
> Priority: Minor
> Labels: client-impacting, cql3
>
> The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
> nearly identical implementations exist in many drivers. There are several
> motivations for making {{DESCRIBE}} part of the CQL language:
> * Eliminate the (fairly complex) duplicate implementations across drivers and
> cqlsh
> * Get closer to allowing drivers to not have to fetch the schema tables.
> (Minor changes to prepared statements are also needed.)
> * Have instantaneous support for new schema features in cqlsh. (You
> currently have to update the bundled python driver.)
> * Support writing out schemas where it makes sense. One good example of this
> is backups. You need to restore the schema before restoring data in the case
> of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
