[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154498#comment-14154498
]
Robert Stupp commented on CASSANDRA-8005:
-----------------------------------------
Drivers need to parse schema tables to route requests directly to the nodes
owning the data. ;)
Unfortunately you might need to change the generated DDL afterwards if you want
to apply it to another C* version (which support other/fewer/more options for
tables or keyspaces).
I'm not sold on taking the DDL from one (e.g. development) cluster and apply it
"as is" to another (e.g. production) cluster - options might be completely
different.
But I could imagine the need for a tool that helps devs + ops to generate and
apply schema diffs - but that would need to support a lot of C* versions and be
aware of different cluster configs, requirements, etc.
> 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)
