cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
Date Mon, 29 Jun 2015 16:29:06 GMT


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

View raw message