CQL3 ne colle plus avec le modèle des « noms de colonnes dynamiques ». Il peut toujours faire des rangées de cassandra arbitrairement larges, mais elles ressemblent à des tables étroites "normales" dans CQL, avec toutes les colonnes nommées et définies. C'est pourquoi CQL3 ne prend plus en charge la fixation d'un default_validation
ou comparator
, etc.
Vous devez lire et comprendre http://www.datastax.com/dev/blog/schema-in-cassandra-1-1 avant de faire quoi que ce soit dans nonbanal CQL3.
La réponse à votre question, cependant, est qu'il est aussi simple que de laisser au large de la default_validation
:
CREATE TABLE userstats (
username varchar PRIMARY KEY,
images counter
) WITH comment='User Stats';
Bien qu'il ne sait pas si vous aviez l'intention d'utiliser plusieurs compteurs par ligne là-bas, puisque vous vouliez un default_validation
. Si vous avez fait, et votre comparator
aurait été varchar
, vous pouvez faire:
CREATE TABLE userstats (
username varchar,
countername varchar,
value counter,
PRIMARY KEY (username, countername)
) WITH comment='User Stats';
..et nous images
être que l'une des counternames.
J'ai essayé d'utiliser votre commande recommandée à partir d'une invite CQL3 et d'obtenir: TSocket read 0 bytes – mithrix
Dans mon expérience, cqlsh est à la traîne des fonctionnalités. Vous devriez essayer d'utiliser directement thrift execute_cql – Alar
@Alar cqlsh n'est pas en retard dans les fonctionnalités cql, car le traitement cql réel est effectué du côté de Cassandra. Cqlsh aide juste à rendre la sortie jolie et fournit de bonnes fonctionnalités de complétion et de readline. Il utilise le même appel d'épargne. –