This interpreter is compatible with any CQL statement supported by Cassandra. Ex:
INSERT INTO users(login,name) VALUES('jdoe','John DOE');SELECT * FROM users WHERE login='jdoe';
USE spark_demo;SELECT * FROM albums_by_country LIMIT 1; SELECT * FROM countries LIMIT 1;SELECT *FROM artistsWHERE login='jlennon';
BEGIN BATCHINSERT INTO users(login,name) VALUES('jdoe','John DOE');INSERT INTO users_preferences(login,account_type) VALUES('jdoe','BASIC');APPLY BATCH;CREATE TABLE IF NOT EXISTS test(key int PRIMARY KEY,value text);
INSERT INTO users(login,name) VALUES('jdoe','John DOE');Insert into users(login,name) vAlues('hsue','Helen SUE');
It is possible to add comments between statements. Single line comments start with thehash sign (#) or double slashes (//). Multi-line comments are enclosed between/** and **/. Ex:
#Single line comment style 1INSERT INTO users(login,name) VALUES('jdoe','John DOE');//Single line comment style 2/**Multi linecomments**/Insert into users(login,name) vAlues('hsue','Helen SUE');
The interpreters is shipped with a built-in syntax validator. This validator onlychecks for basic syntax errors. All CQL-related syntax validation is delegateddirectly to Cassandra
Most of the time, syntax errors are due to missing semi-colons between statements or typo errors.
To make schema discovery easier and more interactive, the following commands are supported:
Command | Description |
---|---|
DESCRIBE CLUSTER; | Show the current cluster name and its partitioner |
DESCRIBE KEYSPACES; | List all existing keyspaces in the cluster and their configuration(replication factor, durable write ...) |
DESCRIBE TABLES; | List all existing keyspaces in the cluster and for each, all the tables name |
DESCRIBE TYPES; | List all existing keyspaces in the cluster and for each, all the types name |
DESCRIBE FUNCTIONS; | List all existing keyspaces in the cluster and for each, all the functions name and arguments |
DESCRIBE AGGREGATES; | List all existing keyspaces in the cluster and for each, all the aggregates name and arguments |
DESCRIBE MATERIALIZED VIEWS; | List all existing keyspaces in the cluster and for each, all the materialized view name |
DESCRIBE KEYSPACE <keyspace name>; | Describe the given keyspace configuration and all its table details (name, columns, ...) |
DESCRIBE TABLE (<keyspace name>).<table name>; | Describe the given table. If the keyspace is not provided, the currentlogged in keyspace is used. If there is no logged in keyspace,the default system keyspace is used. If no table is found, an error message is raised |
DESCRIBE TYPE (<keyspace name>).<type name>; | Describe the given type(UDT). If the keyspace is not provided, the currentlogged in keyspace is used. If there is no logged in keyspace,the default system keyspace is used. If no type is found, an error message is raised |
DESCRIBE FUNCTION (<keyspace name>).<function name>; | Describe the given function. If the keyspace is not provided, the currentlogged in keyspace is used. If there is no logged in keyspace,the default system keyspace is used. If no function is found, an error message is raised |
DESCRIBE AGGREGATE (<keyspace name>).<aggregate name>; | Describe the given aggregate. If the keyspace is not provided, the currentlogged in keyspace is used. If there is no logged in keyspace,the default system keyspace is used. If no aggregate is found, an error message is raised |
DESCRIBE MATERIALIZED VIEW (<keyspace name>).<view name>; | Describe the given materialized view. If the keyspace is not provided, the currentlogged in keyspace is used. If there is no logged in keyspace,the default system keyspace is used. If no materialized view is found, an error message is raised |
The schema objects (cluster, keyspace, table, type, view, function & aggregate) are displayed in a tabular format. There is a drop-down menu on the top left corner to expand objects details. On the top right menu is shown the Icon legend.
Sometimes you want to be able to pass runtime query parameters to your statements.Those parameters are not part of the CQL specs and are specific to the interpreter.Below is the list of all parameters:
Parameter | Syntax | Description |
---|---|---|
Consistency Level | @consistency=value | Apply the given consistency level to all queries in the paragraph |
Serial Consistency Level | @serialConsistency=value | Apply the given serial consistency level to all queries in the paragraph |
Timestamp | @timestamp=long value | Apply the given timestamp to all queries in the paragraph. Please note that timestamp value passed directly in CQL statement will override this value |
Retry Policy | @retryPolicy=value | Apply the given retry policy to all queries in the paragraph |
Fetch Size | @fetchSize=int value | Apply the given fetch size to all queries in the paragraph |
Request Timeout | @requestTimeOut=int value | Apply the given request timeout in millisecs to all queries in the paragraph |
Parameter | Possible Values |
---|---|
Consistency Level | ALL, ANY, ONE, TWO, THREE, QUORUM, LOCAL_ONE, LOCAL_QUORUM, EACH_QUORUM |
Serial Consistency Level | SERIAL, LOCAL_SERIAL |
Timestamp | Any long value |
Retry Policy | DEFAULT, DOWNGRADING_CONSISTENCY, FALLTHROUGH, LOGGING_DEFAULT,LOGGING_DOWNGRADING, LOGGING_FALLTHROUGH |
Fetch Size | Any integer value |
Request Timeout | Any integer value |
CREATE TABLE IF NOT EXISTS spark_demo.ts(key int PRIMARY KEY,value text);TRUNCATE spark_demo.ts;// Timestamp in the past@timestamp=10// Force timestamp directly in the first insertINSERT INTO spark_demo.ts(key,value) VALUES(1,'first insert') USING TIMESTAMP 100;// Select some data to make the clock turnSELECT * FROM spark_demo.albums LIMIT 100;// Now insert using the timestamp parameter set at the beginning(10)INSERT INTO spark_demo.ts(key,value) VALUES(1,'second insert');// Check for the result. You should see 'first insert'SELECT value FROM spark_demo.ts WHERE key=1;
For performance reason, it is better to prepare statements before-hand and reusethem later by providing bound values. This interpreter provides 3 commands to handle prepared andbound statements:
@prepare[statement-name]=...@bind[statement-name]=’text’, 1223, ’2015-07-30 12:00:01’, null, true, [‘list_item1’, ’list_item2’]@bind[statement-name-with-no-bound-value]@remove_prepare[statement-name]
You can use the syntax "@prepare[statement-name]=SELECT ..." to create a prepared statement.The statement-name is mandatory because the interpreter prepares the given statement with theJava driver and saves the generated prepared statement in an internal map, using the providedstatement-name as search key.
@prepare[select]=SELECT * FROM spark_demo.albums LIMIT ?@prepare[select]=SELECT * FROM spark_demo.artists LIMIT ?
Once the statement is prepared (possibly in a separated notebook/paragraph). You can bind values to it:
@bind[select_first]=10
BEGIN BATCH@bind[insert_user]='jdoe','John DOE'UPDATE users SET age = 27 WHERE login='hsue';APPLY BATCH;
To avoid for a prepared statement to stay forever in the prepared statement map, you can use the @remove_prepare[statement-name] syntaxto remove it. Removing a non-existing prepared statement yields no error.
Instead of hard-coding your CQL queries, it is possible to use Zeppelin dynamic form syntax to inject simple value or multiple choices forms.The legacy mustache syntax ( {{ }} ) to bind input text and select form is still supported but is deprecated and will be removed in future releases.
#Secondary index on performer styleSELECT name, country, performerFROM spark_demo.performersWHERE name='${performer=Sheryl Crow|Doof|Fanfarlo|Los Paranoia}'AND styles CONTAINS '${style=Rock}';
Parameter | Default Value |
---|---|
cassandra.cluster | Test Cluster |
cassandra.compression.protocol | NONE, possible values: LZ4, SNAPPY |
cassandra.credentials.password | none |
cassandra.credentials.username | none |
cassandra.hosts | localhost |
cassandra.interpreter.parallelism | 10 |
cassandra.keyspace | system |
cassandra.load.balancing.policy | DEFAULT, or a FQCN of a custom class |
cassandra.max.schema.agreement.wait.second | 10 |
cassandra.native.port | 9042 |
cassandra.pooling.core.connection.per.host.local | Protocol V2 and below: 2, V3 and above: 1 |
cassandra.pooling.core.connection.per.host.remote | Protocol V2 and below: 1, V3 and above: 1 |
cassandra.pooling.heartbeat.interval.seconds | 30 |
cassandra.pooling.idle.timeout.seconds | Test Cluster |
cassandra.pooling.max.connection.per.host.local | Protocol V2 and below: 8, V3 and above: 1 |
cassandra.pooling.max.connection.per.host.remote | Protocol V2 and below: 2, V3 and above: 1 |
cassandra.pooling.max.request.per.connection.local | Protocol V2 and below: 128, V3 and above: 1024 |
cassandra.pooling.max.request.per.connection.remote | Protocol V2 and below: 128, V3 and above: 256 |
cassandra.pooling.new.connection.threshold.local | Protocol V2 and below: 100, V3 and above: 800 |
cassandra.pooling.new.connection.threshold.remote | Protocol V2 and below: 100, V3 and above: 200 |
cassandra.pooling.pool.timeout.millisecs | 5000 |
cassandra.protocol.version | 4 |
cassandra.query.default.consistency | ONE |
cassandra.query.default.fetchSize | 5000 |
cassandra.query.default.serial.consistency | SERIAL |
cassandra.reconnection.policy | DEFAULT, or a FQCN of a custom class |
cassandra.retry.policy | DEFAULT, or a FQCN of a custom class |
cassandra.socket.connection.timeout.millisecs | 500 |
cassandra.socket.read.timeout.millisecs | 12000 |
cassandra.socket.tcp.no_delay | true |
cassandra.speculative.execution.policy | DEFAULT, or a FQCN of a custom class |
com.datastax.driver.core.Session
object is used for all notes and paragraphs.Consequently, if you use the USE keyspace name; statement to log into a keyspace,it will change the keyspace for all current users of the Cassandra interpreter because we only create 1com.datastax.driver.core.Session
object per instance of Cassandra interpreter.com.datastax.driver.core.Session
objects.Beware of resource and memory usage using this binding !com.datastax.driver.core.Session
object as there are distinct notes.@requestTimeOut
runtime optionALTER
statements