Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <23729737.84701293815325952.JavaMail.jira@thor>
Date: Fri, 31 Dec 2010 12:08:45 -0500 (EST)
From: "Eric Evans (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-1709) CQL keyspace and column family
 management
In-Reply-To: <8428624.9311288883265355.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Eric Evans commented on CASSANDRA-1709:
---------------------------------------

{quote}
CREATE KEYSPACE Keyspace1 WITH replication_strategy = 'SimpleStrategy' AND replication_factor = 3;

(I believe we already have the code to turn SimpleStrategy into the full name server-side for the current CLI's benefit.)
{quote}

Sure.

{quote}
For column families I think we should support the SQL syntax for including column metadata at table creation time:

CREATE COLUMNFAMILY users (
   name utf8,
   birth_date long
) 
WITH comparator = utf8;

Although I think Cassandra's way of including indexes w/ the rest of column metadata makes more sense, for CQL we should stick with what SQL describes:

ALTER TABLE users ALTER birth_date TYPE int;
ALTER TABLE users ADD email utf8;
ALTER TABLE USERS DROP email;

DROP gives me pause, since the SQL semantics are "obliterate this column," not just "remove its metadata." Maybe we should use another verb here, like UNDEFINE.

Indexes are special cased:

CREATE INDEX [name] ON users (birth_date);
DROP INDEX users.birth_date_index
{quote}

Yeah, I think I'm on board with this.  I skewed things more towards exposing the column metadata concept in the language, and this abstracts.  This might create confusion for people who've paid attention to internals, or are coming from the RPC interface (one in the same in this case), but it's better for people who know nothing but CQL.  I'm a dreamer, so I'm hoping for a day when the latter is status quo. :)

bq. (I believe SQL index names are scoped per-schema, while ours are per-columnfamily. We should probably change our scoping while it's still easy.)

Could you clarify?

{quote}
Probably controversial: I think we should consider calling {KEYSPACE, COLUMNFAMILY} {SCHEMA, TABLE} for the purposes of CQL: the purpose of CQL is to emphasize similarity, rather than difference, and the main differences have been blurred (schemalessness) or are not supported by CQL (supercolumns).
{quote}

Holy crap.

> CQL keyspace and column family management
> -----------------------------------------
>
>                 Key: CASSANDRA-1709
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1709
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>    Affects Versions: 0.8
>            Reporter: Eric Evans
>            Priority: Minor
>             Fix For: 0.8
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> CQL specification and implementation for schema management.
> This corresponds to the following RPC methods:
> * system_add_column_family()
> * system_add_keyspace()
> * system_drop_keyspace()
> * system_update_keyspace()
> * system_update_columnfamily()

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.