[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153284#comment-14153284
]
Tyler Hobbs commented on CASSANDRA-8005:
----------------------------------------
bq. or, in your proposal of replacing the read of the schema tables by a
string, it would have to parse that string
I'm not suggesting _replacing_ the read of the schema tables, I'm suggesting
_augmenting_ it. Drivers are still free to parse the schema table and expose
schema metadata, but it's not a hard requirement. (For what it's worth, I
think I would be okay with having a column in the schema table that contains
the {{CREATE TABLE}} statement instead of adding a statement to CQL, if that's
a more attractive option to you. I think {{DESCRIBE}} is a better option,
though.)
I still think the other three points need to be addressed.
> 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)
