cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
Date Wed, 01 Oct 2014 01:48:34 GMT


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

View raw message