[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153847#comment-14153847
]
Nick Bailey commented on CASSANDRA-8005:
----------------------------------------
bq. Why is every driver implementing describe in the first place?
I would guess because there is user demand for the feature, but I suppose it
could be an unused feature in the drivers. I'm not sure what the dividing
characteristic between cqlsh and a driver is that puts the responsibility into
cqlsh land and not driver land.
I still say CASSANDRA-7190 presents a good reason for having this server side.
I suppose you could dump the relevant rows from the schema tables along with
the backup but then you are putting the recreation of the create statement
burden on any C* backup tools (OpsCenter or otherwise).
> 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: cql3
> Fix For: 3.0
>
>
> 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)
