[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14605863#comment-14605863
]
Aleksey Yeschenko commented on CASSANDRA-8005:
----------------------------------------------
That's where we fundamentally disagree, then.
I believe in Postgres approach. What we need is a (versioned?) virtual table
set exposing a fixed and documented data dictionary that you could rely on,
that would map 1-1 to CQL syntax, more or less.
Let's see first how CASSANDRA-6717 and CASSANDRA-8099 pan out.
bq. We're now faced with supporting multiple metadata implementations, and
generating CQL from them.
Yes. For now. Long term, 2.2 metadata will be dropped from the drivers and just
one implementation will remain.
> 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: client-impacting, cql3
>
> 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)
