[ 
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154208#comment-14154208
 ] 

Nick Bailey commented on CASSANDRA-8005:
----------------------------------------

I agree that backup tools do need to be a bit more intelligent. They do need to 
attempt to detect conflicts in the existing schema and the schema of the data 
in the backup. I'm not convinced that means they have to know how to inspect 
schema tables though. Especially since we are already saying we want to 
reformat those tables. At least with a create statement, a backup tool will 
have a common format to parse and compare across versions of Cassandra. We are 
already talking about reformatting the schema tables in CASSANDRA-6717, so we 
already know that won't be true for the schema tables. I doubt we want to 
commit to trying to guarantee the format of the schema tables stays somewhat 
consistent.

What are the downsides for server side DESC support?

> 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)

Reply via email to