cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1709) CQL keyspace and column family management
Date Fri, 31 Dec 2010 17:08:45 GMT

    [ 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.


Mime
View raw message