You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by sl...@apache.org on 2016/06/27 18:34:18 UTC
[23/34] cassandra git commit: Reorganize document
http://git-wip-us.apache.org/repos/asf/cassandra/blob/54f7335c/doc/source/cql.rst
----------------------------------------------------------------------
diff --git a/doc/source/cql.rst b/doc/source/cql.rst
deleted file mode 100644
index 8d185a2..0000000
--- a/doc/source/cql.rst
+++ /dev/null
@@ -1,4114 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-.. or more contributor license agreements. See the NOTICE file
-.. distributed with this work for additional information
-.. regarding copyright ownership. The ASF licenses this file
-.. to you under the Apache License, Version 2.0 (the
-.. "License"); you may not use this file except in compliance
-.. with the License. You may obtain a copy of the License at
-..
-.. http://www.apache.org/licenses/LICENSE-2.0
-..
-.. Unless required by applicable law or agreed to in writing, software
-.. distributed under the License is distributed on an "AS IS" BASIS,
-.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-.. See the License for the specific language governing permissions and
-.. limitations under the License.
-
-.. highlight:: sql
-
-.. _UUID: https://en.wikipedia.org/wiki/Universally_unique_identifier
-
-The Cassandra Query Language (CQL)
-==================================
-
-This document describes the Cassandra Query Language (CQL) [#]_. Note that this document describes the last version of
-the languages. However, the `changes <#changes>`_ section provides the diff between the different versions of CQL.
-
-CQL offers a model close to SQL in the sense that data is put in *tables* containing *rows* of *columns*. For
-that reason, when used in this document, these terms (tables, rows and columns) have the same definition than they have
-in SQL. But please note that as such, they do **not** refer to the concept of rows and columns found in the deprecated
-thrift API (and earlier version 1 and 2 of CQL).
-
-.. _definitions:
-
-Definitions
------------
-
-.. _conventions:
-
-Conventions
-^^^^^^^^^^^
-
-To aid in specifying the CQL syntax, we will use the following conventions in this document:
-
-- Language rules will be given in an informal `BNF variant
- <http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form#Variants>`_ notation. In particular, we'll use square brakets
- (``[ item ]``) for optional items, ``*`` and ``+`` for repeated items (where ``+`` imply at least one).
-- The grammar will also use the following convention for convenience: non-terminal term will be lowercase (and link to
- their definition) while terminal keywords will be provided "all caps". Note however that keywords are
- :ref:`identifiers` and are thus case insensitive in practice. We will also define some early construction using
- regexp, which we'll indicate with ``re(<some regular expression>)``.
-- The grammar is provided for documentation purposes and leave some minor details out. For instance, the comma on the
- last column definition in a ``CREATE TABLE`` statement is optional but supported if present even though the grammar in
- this document suggests otherwise. Also, not everything accepted by the grammar is necessarily valid CQL.
-- References to keywords or pieces of CQL code in running text will be shown in a ``fixed-width font``.
-
-
-.. _identifiers:
-
-Identifiers and keywords
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The CQL language uses *identifiers* (or *names*) to identify tables, columns and other objects. An identifier is a token
-matching the regular expression ``[a-zA-Z][a-zA-Z0-9_]*``.
-
-A number of such identifiers, like ``SELECT`` or ``WITH``, are *keywords*. They have a fixed meaning for the language
-and most are reserved. The list of those keywords can be found in :ref:`appendix-A`.
-
-Identifiers and (unquoted) keywords are case insensitive. Thus ``SELECT`` is the same than ``select`` or ``sElEcT``, and
-``myId`` is the same than ``myid`` or ``MYID``. A convention often used (in particular by the samples of this
-documentation) is to use upper case for keywords and lower case for other identifiers.
-
-There is a second kind of identifiers called *quoted identifiers* defined by enclosing an arbitrary sequence of
-characters (non empty) in double-quotes(``"``). Quoted identifiers are never keywords. Thus ``"select"`` is not a
-reserved keyword and can be used to refer to a column (note that using this is particularly advised), while ``select``
-would raise a parsing error. Also, contrarily to unquoted identifiers and keywords, quoted identifiers are case
-sensitive (``"My Quoted Id"`` is *different* from ``"my quoted id"``). A fully lowercase quoted identifier that matches
-``[a-zA-Z][a-zA-Z0-9_]*`` is however *equivalent* to the unquoted identifier obtained by removing the double-quote (so
-``"myid"`` is equivalent to ``myid`` and to ``myId`` but different from ``"myId"``). Inside a quoted identifier, the
-double-quote character can be repeated to escape it, so ``"foo "" bar"`` is a valid identifier.
-
-.. note:: *quoted identifiers* allows to declare columns with arbitrary names, and those can sometime clash with
- specific names used by the server. For instance, when using conditional update, the server will respond with a
- result-set containing a special result named ``"[applied]"``. If you\u2019ve declared a column with such a name, this
- could potentially confuse some tools and should be avoided. In general, unquoted identifiers should be preferred but
- if you use quoted identifiers, it is strongly advised to avoid any name enclosed by squared brackets (like
- ``"[applied]"``) and any name that looks like a function call (like ``"f(x)"``).
-
-More formally, we have:
-
-.. productionlist::
- identifier: `unquoted_identifier` | `quoted_identifier`
- unquoted_identifier: re('[a-zA-Z][a-zA-Z0-9_]*')
- quoted_identifier: '"' (any character where " can appear if doubled)+ '"'
-
-.. _constants:
-
-Constants
-^^^^^^^^^
-
-CQL defines the following kind of *constants*:
-
-.. productionlist::
- constant: `string` | `integer` | `float` | `boolean` | `uuid` | `blob` | NULL
- string: '\'' (any character where ' can appear if doubled)+ '\''
- : '$$' (any character other than '$$') '$$'
- integer: re('-?[0-9]+')
- float: re('-?[0-9]+(\.[0-9]*)?([eE][+-]?[0-9+])?') | NAN | INFINITY
- boolean: TRUE | FALSE
- uuid: `hex`{8}-`hex`{4}-`hex`{4}-`hex`{4}-`hex`{12}
- hex: re("[0-9a-fA-F]")
- blob: '0' ('x' | 'X') `hex`+
-
-In other words:
-
-- A string constant is an arbitrary sequence of characters enclosed by single-quote(``'``). A single-quote
- can be included by repeating it, e.g. ``'It''s raining today'``. Those are not to be confused with quoted
- :ref:`identifiers` that use double-quotes. Alternatively, a string can be defined by enclosing the arbitrary sequence
- of characters by two dollar characters, in which case single-quote can be use without escaping (``$$It's raining
- today$$``). That latter form is often used when defining :ref:`user-defined functions <udfs>` to avoid having to
- escape single-quote characters in function body (as they are more likely to occur than ``$$``).
-- Integer, float and boolean constant are defined as expected. Note however than float allows the special ``NaN`` and
- ``Infinity`` constants.
-- CQL supports UUID_ constants.
-- Blobs content are provided in hexadecimal and prefixed by ``0x``.
-- The special ``NULL`` constant denotes the absence of value.
-
-For how these constants are typed, see the :ref:`data-types` section.
-
-Terms
-^^^^^
-
-CQL has the notion of a *term*, which denotes the kind of values that CQL support. Terms are defined by:
-
-.. productionlist::
- term: `constant` | `literal` | `function_call` | `type_hint` | `bind_marker`
- literal: `collection_literal` | `udt_literal` | `tuple_literal`
- function_call: `identifier` '(' [ `term` (',' `term`)* ] ')'
- type_hint: '(' `cql_type` `)` term
- bind_marker: '?' | ':' `identifier`
-
-A term is thus one of:
-
-- A :ref:`constant <constants>`.
-- A literal for either :ref:`a collection <collections>`, :ref:`a user-defined type <udts>` or :ref:`a tuple <tuples>`
- (see the linked sections for details).
-- A function call: see :ref:`the section on functions <functions>` for details on which :ref:`native function
- <native-functions>` exists and how to define your own :ref:`user-defined ones <user-defined-functions>`.
-- A *type hint*: see the :ref:`related section <type-hints>` for details.
-- A bind marker, which denotes a variable to be bound at execution time. See the section on :ref:`prepared-statements`
- for details. A bind marker can be either anonymous (``?``) or named (``:some_name``). The latter form provides a more
- convenient way to refer to the variable for binding it and should generally be preferred.
-
-
-Comments
-^^^^^^^^
-
-A comment in CQL is a line beginning by either double dashes (``--``) or double slash (``//``).
-
-Multi-line comments are also supported through enclosure within ``/*`` and ``*/`` (but nesting is not supported).
-
-::
-
- \u2014 This is a comment
- // This is a comment too
- /* This is
- a multi-line comment */
-
-Statements
-^^^^^^^^^^
-
-CQL consists of statements that can be divided in the following categories:
-
-- :ref:`data-definition` statements, to define and change how the data is stored (keyspaces and tables).
-- :ref:`data-manipulation` statements, for selecting, inserting and deleting data.
-- :ref:`index-and-views` statements.
-- :ref:`roles-and-permissions` statements.
-- :ref:`udfs` statements.
-- :ref:`udts` statements.
-- :ref:`triggers` statements.
-
-All the statements are listed below and are described in the rest of this documentation (see links above):
-
-.. productionlist::
- cql_statement: `statement` [ ';' ]
- statement: `ddl_statement`
- : | `dml_statement`
- : | `index_or_view_statement`
- : | `role_or_permission_statement`
- : | `udf_statement`
- : | `udt_statement`
- : | `trigger_statement`
- ddl_statement: `use_statement`
- : | `create_keyspace_statement`
- : | `alter_keyspace_statement`
- : | `drop_keyspace_statement`
- : | `create_table_statement`
- : | `alter_table_statement`
- : | `drop_table_statement`
- : | `truncate_statement`
- dml_statement: `select_statement`
- : | `insert_statement`
- : | `update_statement`
- : | `delete_statement`
- : | `batch_statement`
- index_or_view_statement: `create_index_statement`
- : | `drop_index_statement`
- : | `create_materialized_view_statement`
- : | `drop_materialized_view_statement`
- role_or_permission_statement: `create_role_statement`
- : | `alter_role_statement`
- : | `drop_role_statement`
- : | `grant_role_statement`
- : | `revoke_role_statement`
- : | `list_role_statement`
- : | `grant_permission_statement`
- : | `revoke_permission_statement`
- : | `list_permission_statement`
- : | `create_user_statement`
- : | `alter_user_statement`
- : | `drop_user_statement`
- : | `list_user_statement`
- udf_statement: `create_function_statement`
- : | `drop_function_statement`
- : | `create_aggregate_statement`
- : | `drop_aggregate_statement`
- udt_statement: `create_type_statement`
- : | `alter_type_statement`
- : | `drop_type_statement`
- trigger_statement: `create_trigger_statement`
- : | `drop_trigger_statement`
-
-.. _prepared-statements:
-
-Prepared Statements
-^^^^^^^^^^^^^^^^^^^
-
-CQL supports *prepared statements*. Prepared statements are an optimization that allows to parse a query only once but
-execute it multiple times with different concrete values.
-
-Any statement that uses at least one bind marker (see :token:`bind_marker`) will need to be *prepared*. After which the statement
-can be *executed* by provided concrete values for each of its marker. The exact details of how a statement is prepared
-and then executed depends on the CQL driver used and you should refer to your driver documentation.
-
-
-.. _data-types:
-
-Data Types
-----------
-
-CQL is a typed language and supports a rich set of data types, including :ref:`native types <native-types>`,
-:ref:`collection types <collections>`, :ref:`user-defined types <udts>`, :ref:`tuple types <tuples>` and :ref:`custom
-types <custom-types>`:
-
-.. productionlist::
- cql_type: `native_type` | `collection_type` | `user_defined_type` | `tuple_type` | `custom_type`
-
-
-.. _native-types:
-
-Native Types
-^^^^^^^^^^^^
-
-The native types supported by CQL are:
-
-.. productionlist::
- native_type: ASCII
- : | BIGINT
- : | BLOB
- : | BOOLEAN
- : | COUNTER
- : | DATE
- : | DECIMAL
- : | DOUBLE
- : | FLOAT
- : | INET
- : | INT
- : | SMALLINT
- : | TEXT
- : | TIME
- : | TIMESTAMP
- : | TIMEUUID
- : | TINYINT
- : | UUID
- : | VARCHAR
- : | VARINT
-
-The following table gives additional informations on the native data types, and on which kind of :ref:`constants
-<constants>` each type supports:
-
-=============== ===================== ==================================================================================
- type constants supported description
-=============== ===================== ==================================================================================
- ``ascii`` :token:`string` ASCII character string
- ``bigint`` :token:`integer` 64-bit signed long
- ``blob`` :token:`blob` Arbitrary bytes (no validation)
- ``boolean`` :token:`boolean` Either ``true`` or ``false``
- ``counter`` :token:`integer` Counter column (64-bit signed value). See :ref:`counters` for details
- ``date`` :token:`integer`, A date (with no corresponding time value). See :ref:`dates` below for details
- :token:`string`
- ``decimal`` :token:`integer`, Variable-precision decimal
- :token:`float`
- ``double`` :token:`integer` 64-bit IEEE-754 floating point
- :token:`float`
- ``float`` :token:`integer`, 32-bit IEEE-754 floating point
- :token:`float`
- ``inet`` :token:`string` An IP address, either IPv4 (4 bytes long) or IPv6 (16 bytes long). Note that
- there is no ``inet`` constant, IP address should be input as strings
- ``int`` :token:`integer` 32-bit signed int
- ``smallint`` :token:`integer` 16-bit signed int
- ``text`` :token:`string` UTF8 encoded string
- ``time`` :token:`integer`, A time (with no corresponding date value) with nanosecond precision. See
- :token:`string` :ref:`times` below for details
- ``timestamp`` :token:`integer`, A timestamp (date and time) with millisecond precision. See :ref:`timestamps`
- :token:`string` below for details
- ``timeuuid`` :token:`uuid` Version 1 UUID_, generally used as a \u201cconflict-free\u201d timestamp. Also see
- :ref:`timeuuid-functions`
- ``tinyint`` :token:`integer` 8-bit signed int
- ``uuid`` :token:`uuid` A UUID_ (of any version)
- ``varchar`` :token:`string` UTF8 encoded string
- ``varint`` :token:`integer` Arbitrary-precision integer
-=============== ===================== ==================================================================================
-
-.. _counters:
-
-Counters
-~~~~~~~~
-
-The ``counter`` type is used to define *counter columns*. A counter column is a column whose value is a 64-bit signed
-integer and on which 2 operations are supported: incrementing and decrementing (see the :ref:`UPDATE statement
-<update-statement>` for syntax). Note that the value of a counter cannot be set: a counter does not exist until first
-incremented/decremented, and that first increment/decrement is made as if the prior value was 0.
-
-.. _counter-limitations:
-
-Counters have a number of important limitations:
-
-- They cannot be used for columns part of the ``PRIMARY KEY`` of a table.
-- A table that contains a counter can only contain counters. In other words, either all the columns of a table outside
- the ``PRIMARY KEY`` have the ``counter`` type, or none of them have it.
-- Counters do not support :ref:`expiration <ttls>`.
-- The deletion of counters is supported, but is only guaranteed to work the first time you delete a counter. In other
- words, you should not re-update a counter that you have deleted (if you do, proper behavior is not guaranteed).
-- Counter updates are, by nature, not `idemptotent <https://en.wikipedia.org/wiki/Idempotence>`__. An important
- consequence is that if a counter update fails unexpectedly (timeout or loss of connection to the coordinator node),
- the client has no way to know if the update has been applied or not. In particular, replaying the update may or may
- not lead to an over count.
-
-.. _timestamps:
-
-Working with timestamps
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Values of the ``timestamp`` type are encoded as 64-bit signed integers representing a number of milliseconds since the
-standard base time known as `the epoch <https://en.wikipedia.org/wiki/Unix_time>`__: January 1 1970 at 00:00:00 GMT.
-
-Timestamps can be input in CQL either using their value as an :token:`integer`, or using a :token:`string` that
-represents an `ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601>`__ date. For instance, all of the values below are
-valid ``timestamp`` values for Mar 2, 2011, at 04:05:00 AM, GMT:
-
-- ``1299038700000``
-- ``'2011-02-03 04:05+0000'``
-- ``'2011-02-03 04:05:00+0000'``
-- ``'2011-02-03 04:05:00.000+0000'``
-- ``'2011-02-03T04:05+0000'``
-- ``'2011-02-03T04:05:00+0000'``
-- ``'2011-02-03T04:05:00.000+0000'``
-
-The ``+0000`` above is an RFC 822 4-digit time zone specification; ``+0000`` refers to GMT. US Pacific Standard Time is
-``-0800``. The time zone may be omitted if desired (``'2011-02-03 04:05:00'``), and if so, the date will be interpreted
-as being in the time zone under which the coordinating Cassandra node is configured. There are however difficulties
-inherent in relying on the time zone configuration being as expected, so it is recommended that the time zone always be
-specified for timestamps when feasible.
-
-The time of day may also be omitted (``'2011-02-03'`` or ``'2011-02-03+0000'``), in which case the time of day will
-default to 00:00:00 in the specified or default time zone. However, if only the date part is relevant, consider using
-the :ref:`date <dates>` type.
-
-.. _dates:
-
-Working with dates
-^^^^^^^^^^^^^^^^^^
-
-Values of the ``date`` type are encoded as 32-bit unsigned integers representing a number of days with \u201cthe epoch\u201d at
-the center of the range (2^31). Epoch is January 1st, 1970
-
-As for :ref:`timestamp <timestamps>`, a date can be input either as an :token:`integer` or using a date
-:token:`string`. In the later case, the format should be ``yyyy-mm-dd`` (so ``'2011-02-03'`` for instance).
-
-.. _times:
-
-Working with times
-^^^^^^^^^^^^^^^^^^
-
-Values of the ``time`` type are encoded as 64-bit signed integers representing the number of nanoseconds since midnight.
-
-As for :ref:`timestamp <timestamps>`, a time can be input either as an :token:`integer` or using a :token:`string`
-representing the time. In the later case, the format should be ``hh:mm:ss[.fffffffff]`` (where the sub-second precision
-is optional and if provided, can be less than the nanosecond). So for instance, the following are valid inputs for a
-time:
-
-- ``'08:12:54'``
-- ``'08:12:54.123'``
-- ``'08:12:54.123456'``
-- ``'08:12:54.123456789'``
-
-
-.. _collections:
-
-Collections
-^^^^^^^^^^^
-
-CQL supports 3 kind of collections: :ref:`maps`, :ref:`sets` and :ref:`lists`. The types of those collections is defined
-by:
-
-.. productionlist::
- collection_type: MAP '<' `cql_type` ',' `cql_type` '>'
- : | SET '<' `cql_type` '>'
- : | LIST '<' `cql_type` '>'
-
-and their values can be inputd using collection literals:
-
-.. productionlist::
- collection_literal: `map_literal` | `set_literal` | `list_literal`
- map_literal: '{' [ `term` ':' `term` (',' `term` : `term`)* ] '}'
- set_literal: '{' [ `term` (',' `term`)* ] '}'
- list_literal: '[' [ `term` (',' `term`)* ] ']'
-
-Note however that neither :token:`bind_marker` nor ``NULL`` are supported inside collection literals.
-
-Noteworthy characteristics
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Collections are meant for storing/denormalizing relatively small amount of data. They work well for things like \u201cthe
-phone numbers of a given user\u201d, \u201clabels applied to an email\u201d, etc. But when items are expected to grow unbounded (\u201call
-messages sent by a user\u201d, \u201cevents registered by a sensor\u201d...), then collections are not appropriate and a specific table
-(with clustering columns) should be used. Concretely, (non-frozen) collections have the following noteworthy
-characteristics and limitations:
-
-- Individual collections are not indexed internally. Which means that even to access a single element of a collection,
- the while collection has to be read (and reading one is not paged internally).
-- While insertion operations on sets and maps never incur a read-before-write internally, some operations on lists do.
- Further, some lists operations are not idempotent by nature (see the section on :ref:`lists <lists>` below for
- details), making their retry in case of timeout problematic. It is thus advised to prefer sets over lists when
- possible.
-
-Please note that while some of those limitations may or may not be removed/improved upon in the future, it is a
-anti-pattern to use a (single) collection to store large amounts of data.
-
-.. _maps:
-
-Maps
-~~~~
-
-A ``map`` is a (sorted) set of key-value pairs, where keys are unique and the map is sorted by its keys. You can define
-and insert a map with::
-
- CREATE TABLE users (
- id text PRIMARY KEY,
- name text,
- favs map<text, text> // A map of text keys, and text values
- );
-
- INSERT INTO users (id, name, favs)
- VALUES ('jsmith', 'John Smith', { 'fruit' : 'Apple', 'band' : 'Beatles' });
-
- // Replace the existing map entirely.
- UPDATE users SET favs = { 'fruit' : 'Banana' } WHERE id = 'jsmith';
-
-Further, maps support:
-
-- Updating or inserting one or more elements::
-
- UPDATE users SET favs['author'] = 'Ed Poe' WHERE id = 'jsmith';
- UPDATE users SET favs = favs + { 'movie' : 'Cassablanca', 'band' : 'ZZ Top' } WHERE id = 'jsmith';
-
-- Removing one or more element (if an element doesn't exist, removing it is a no-op but no error is thrown)::
-
- DELETE favs['author'] FROM users WHERE id = 'jsmith';
- UPDATE users SET favs = favs - { 'movie', 'band'} WHERE id = 'jsmith';
-
- Note that for removing multiple elements in a ``map``, you remove from it a ``set`` of keys.
-
-Lastly, TTLs are allowed for both ``INSERT`` and ``UPDATE``, but in both case the TTL set only apply to the newly
-inserted/updated elements. In other words::
-
- UPDATE users USING TTL 10 SET favs['color'] = 'green' WHERE id = 'jsmith';
-
-will only apply the TTL to the ``{ 'color' : 'green' }`` record, the rest of the map remaining unaffected.
-
-
-.. _sets:
-
-Sets
-~~~~
-
-A ``set`` is a (sorted) collection of unique values. You can define and insert a map with::
-
- CREATE TABLE images (
- name text PRIMARY KEY,
- owner text,
- tags set<text> // A set of text values
- );
-
- INSERT INTO images (name, owner, tags)
- VALUES ('cat.jpg', 'jsmith', { 'pet', 'cute' });
-
- // Replace the existing set entirely
- UPDATE images SET tags = { 'kitten', 'cat\u2019, 'lol' } WHERE id = 'jsmith';
-
-Further, sets support:
-
-- Adding one or multiple elements (as this is a set, inserting an already existing element is a no-op)::
-
- UPDATE images SET tags = tags + { 'gray', 'cuddly' } WHERE name = 'cat.jpg';
-
-- Removing one or multiple elements (if an element doesn't exist, removing it is a no-op but no error is thrown)::
-
- UPDATE images SET tags = tags - { 'cat' } WHERE name = 'cat.jpg';
-
-Lastly, as for :ref:`maps <maps>`, TTLs if used only apply to the newly inserted values.
-
-.. _lists:
-
-Lists
-~~~~~
-
-.. note:: As mentioned above and further discussed at the end of this section, lists have limitations and specific
- performance considerations that you should take into account before using them. In general, if you can use a
- :ref:`set <sets>` instead of list, always prefer a set.
-
-A ``list`` is a (sorted) collection of non-unique values where elements are ordered by there position in the list. You
-can define and insert a list with::
-
- CREATE TABLE plays (
- id text PRIMARY KEY,
- game text,
- players int,
- scores list<int> // A list of integers
- )
-
- INSERT INTO plays (id, game, players, scores)
- VALUES ('123-afde', 'quake', 3, [17, 4, 2]);
-
- // Replace the existing list entirely
- UPDATE plays SET scores = [ 3, 9, 4] WHERE id = '123-afde';
-
-Further, lists support:
-
-- Appending and prepending values to a list::
-
- UPDATE plays SET players = 5, scores = scores + [ 14, 21 ] WHERE id = '123-afde';
- UPDATE plays SET players = 6, scores = [ 3 ] + scores WHERE id = '123-afde';
-
-- Setting the value at a particular position in the list. This imply that the list has a pre-existing element for that
- position or an error will be thrown that the list is too small::
-
- UPDATE plays SET scores[1] = 7 WHERE id = '123-afde';
-
-- Removing an element by its position in the list. This imply that the list has a pre-existing element for that position
- or an error will be thrown that the list is too small. Further, as the operation removes an element from the list, the
- list size will be diminished by 1, shifting the position of all the elements following the one deleted::
-
- DELETE scores[1] FROM plays WHERE id = '123-afde';
-
-- Deleting *all* the occurrences of particular values in the list (if a particular element doesn't occur at all in the
- list, it is simply ignored and no error is thrown)::
-
- UPDATE plays SET scores = scores - [ 12, 21 ] WHERE id = '123-afde';
-
-.. warning:: The append and prepend operations are not idempotent by nature. So in particular, if one of these operation
- timeout, then retrying the operation is not safe and it may (or may not) lead to appending/prepending the value
- twice.
-
-.. warning:: Setting and removing an element by position and removing occurences of particular values incur an internal
- *read-before-write*. They will thus run more slowly and take more ressources than usual updates (with the exclusion
- of conditional write that have their own cost).
-
-Lastly, as for :ref:`maps <maps>`, TTLs when used only apply to the newly inserted values.
-
-.. _udts:
-
-User-Defined Types
-^^^^^^^^^^^^^^^^^^
-
-CQL support the definition of user-defined types (UDT for short). Such a type can be created, modified and removed using
-the :token:`create_type_statement`, :token:`alter_type_statement` and :token:`drop_type_statement` described below. But
-once created, a UDT is simply referred to by its name:
-
-.. productionlist::
- user_defined_type: `udt_name`
- udt_name: [ `keyspace_name` '.' ] `identifier`
-
-
-Creating a UDT
-~~~~~~~~~~~~~~
-
-Creating a new user-defined type is done using a ``CREATE TYPE`` statement defined by:
-
-.. productionlist::
- create_type_statement: CREATE TYPE [ IF NOT EXISTS ] `udt_name`
- : '(' `field_definition` ( ',' `field_definition` )* ')'
- field_definition: `identifier` `cql_type`
-
-A UDT has a name (used to declared columns of that type) and is a set of named and typed fields. Fields name can be any
-type, including collections or other UDT. For instance::
-
- CREATE TYPE phone (
- country_code int,
- number text,
- )
-
- CREATE TYPE address (
- street text,
- city text,
- zip int,
- phones map<text, phone>
- )
-
- CREATE TABLE user (
- name text PRIMARY KEY,
- addresses map<text, frozen<address>>
- )
-
-Note that:
-
-- Attempting to create an already existing type will result in an error unless the ``IF NOT EXISTS`` option is used. If
- it is used, the statement will be a no-op if the type already exists.
-- A type is intrinsically bound to the keyspace in which it is created, and can only be used in that keyspace. At
- creation, if the type name is prefixed by a keyspace name, it is created in that keyspace. Otherwise, it is created in
- the current keyspace.
-- As of Cassandra |version|, UDT have to be frozen in most cases, hence the ``frozen<address>`` in the table definition
- above. Please see the section on :ref:`frozen <frozen>` for more details.
-
-UDT literals
-~~~~~~~~~~~~
-
-Once a used-defined type has been created, value can be input using a UDT literal:
-
-.. productionlist::
- udt_literal: '{' `identifier` ':' `term` ( ',' `identifier` ':' `term` )* '}'
-
-In other words, a UDT literal is like a :ref:`map <maps>` literal but its keys are the names of the fields of the type.
-For instance, one could insert into the table define in the previous section using::
-
- INSERT INTO user (name, addresses)
- VALUES ('z3 Pr3z1den7', {
- 'home' : {
- street: '1600 Pennsylvania Ave NW',
- city: 'Washington',
- zip: '20500',
- phones: { 'cell' : { country_code: 1, number: '202 456-1111' },
- 'landline' : { country_code: 1, number: '...' } }
- }
- 'work' : {
- street: '1600 Pennsylvania Ave NW',
- city: 'Washington',
- zip: '20500',
- phones: { 'fax' : { country_code: 1, number: '...' } }
- }
- })
-
-To be valid, a UDT literal should only include fields defined by the type it is a literal of, but it can omit some field
-(in which case those will be ``null``).
-
-Altering a UDT
-~~~~~~~~~~~~~~
-
-An existing user-defined type can be modified using an ``ALTER TYPE`` statement:
-
-.. productionlist::
- alter_type_statement: ALTER TYPE `udt_name` `alter_type_modification`
- alter_type_modification: ALTER `identifier` TYPE `cql_type`
- : | ADD `field_definition`
- : | RENAME `identifier` TO `identifier` ( `identifier` TO `identifier` )*
-
-You can:
-
-- modify the type of particular field (``ALTER TYPE address ALTER zip TYPE bigint``). The restrictions for such change
- are the same than when :ref:`altering the type of column <alter-table>`.
-- add a new field to the type (``ALTER TYPE address ADD country text``). That new field will be ``null`` for any values
- of the type created before the addition.
-- rename the fields of the type (``ALTER TYPE address RENAME zip TO zipcode``).
-
-Dropping a UDT
-~~~~~~~~~~~~~~
-
-You can drop an existing user-defined type using a ``DROP TYPE`` statement:
-
-.. productionlist::
- drop_type_statement: DROP TYPE [ IF EXISTS ] `udt_name`
-
-Dropping a type results in the immediate, irreversible removal of that type. However, attempting to drop a type that is
-still in use by another type, table or function will result in an error.
-
-If the type dropped does not exist, an error will be returned unless ``IF EXISTS`` is used, in which case the operation
-is a no-op.
-
-.. _tuples:
-
-Tuples
-^^^^^^
-
-CQL also support tuples and tuple types (where the elements can be of different types). Functionally, tuples can be
-though as anonymous UDT with anonymous fields. Tuple types and tuple literals are defined by:
-
-.. productionlist::
- tuple_type: TUPLE '<' `cql_type` ( ',' `cql_type` )* '>'
- tuple_literal: '(' `term` ( ',' `term` )* ')'
-
-and can be used thusly::
-
- CREATE TABLE durations (
- event text,
- duration tuple<int, text>,
- )
-
- INSERT INTO durations (event, duration) VALUES ('ev1', (3, 'hours'));
-
-Unlike other "composed" types (collections and UDT), a tuple is always :ref:`frozen <frozen>` (without the need of the
-`frozen` keyword) and it is not possible to update only some elements of a tuple (without updating the whole tuple).
-Also, a tuple literal should always have the same number of value than declared in the type it is a tuple of (some of
-those values can be null but they need to be explicitly declared as so).
-
-.. _custom-types:
-
-Custom Types
-^^^^^^^^^^^^
-
-.. note:: Custom types exists mostly for backward compatiliby purposes and their usage is discouraged. Their usage is
- complex, not user friendly and the other provided types, particularly :ref:`user-defined types <udts>`, should almost
- always be enough.
-
-A custom type is defined by:
-
-.. productionlist::
- custom_type: `string`
-
-A custom type is a :token:`string` that contains the name of Java class that extends the server side ``AbstractType``
-class and that can be loaded by Cassandra (it should thus be in the ``CLASSPATH`` of every node running Cassandra). That
-class will define what values are valid for the type and how the time sorts when used for a clustering column. For any
-other purpose, a value of a custom type is the same than that of a ``blob``, and can in particular be input using the
-:token:`blob` literal syntax.
-
-
-.. _data-definition:
-
-Data Definition
----------------
-
-CQL stores data in *tables*, whose schema defines the layout of said data in the table, and those tables are grouped in
-*keyspaces*. A keyspace defines a number of options that applies to all the tables it contains, most prominently of
-which is the :ref:`replication strategy <replication-strategy>` used by the keyspace. It is generally encouraged to use
-one keyspace by *application*, and thus many cluster may define only one keyspace.
-
-This section describes the statements used to create, modify, and remove those keyspace and tables.
-
-Common definitions
-^^^^^^^^^^^^^^^^^^
-
-The names of the keyspaces and tables are defined by the following grammar:
-
-.. productionlist::
- keyspace_name: `name`
- table_name: [ `keyspace_name` '.' ] `name`
- name: `unquoted_name` | `quoted_name`
- unquoted_name: re('[a-zA-Z_0-9]{1, 48}')
- quoted_name: '"' `unquoted_name` '"'
-
-Both keyspace and table name should be comprised of only alphanumeric characters, cannot be empty and are limited in
-size to 48 characters (that limit exists mostly to avoid filenames (which may include the keyspace and table name) to go
-over the limits of certain file systems). By default, keyspace and table names are case insensitive (``myTable`` is
-equivalent to ``mytable``) but case sensitivity can be forced by using double-quotes (``"myTable"`` is different from
-``mytable``).
-
-Further, a table is always part of a keyspace and a table name can be provided fully-qualified by the keyspace it is
-part of. If is is not fully-qualified, the table is assumed to be in the *current* keyspace (see :ref:`USE statement
-<use-statement>`).
-
-We also define the notion of statement options for use in the following section:
-
-.. productionlist::
- options: `option` ( AND `option` )*
- option: `identifier` '=' ( `identifier` | `constant` | `map_literal` )
-
-.. _create-keyspace-statement:
-
-CREATE KEYSPACE
-^^^^^^^^^^^^^^^
-
-A keyspace is created using a ``CREATE KEYSPACE`` statement:
-
-.. productionlist::
- create_keyspace_statement: CREATE KEYSPACE [ IF NOT EXISTS ] `keyspace_name` WITH `options`
-
-For instance::
-
- CREATE KEYSPACE Excelsior
- WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
-
- CREATE KEYSPACE Excalibur
- WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : 1, 'DC2' : 3}
- AND durable_writes = false;
-
-
-.. _create-keyspace-options:
-The supported ``options`` are:
-
-=================== ========== =========== ========= ===================================================================
-name kind mandatory default description
-=================== ========== =========== ========= ===================================================================
-``replication`` *map* yes The replication strategy and options to use for the keyspace (see
- details below).
-``durable_writes`` *simple* no true Whether to use the commit log for updates on this keyspace
- (disable this option at your own risk!).
-=================== ========== =========== ========= ===================================================================
-
-The ``replication`` property is mandatory and must at least contains the ``'class'`` sub-option which defines the
-:ref:`replication strategy <replication-strategy>` class to use. The rest of the sub-options depends on what replication
-strategy is used. By default, Cassandra support the following ``'class'``:
-
-- ``'SimpleStrategy'``: A simple strategy that defines a replication factor for the whole cluster. The only sub-options
- supported is ``'replication_factor'`` to define that replication factor and is mandatory.
-- ``'NetworkTopologyStrategy'``: A replication strategy that allows to set the replication factor independently for
- each data-center. The rest of the sub-options are key-value pairs where a key is a data-center name and its value is
- the associated replication factor.
-
-Attempting to create a keyspace that already exists will return an error unless the ``IF NOT EXISTS`` option is used. If
-it is used, the statement will be a no-op if the keyspace already exists.
-
-.. _use-statement:
-
-USE
-^^^
-
-The ``USE`` statement allows to change the *current* keyspace (for the *connection* on which it is executed). A number
-of objects in CQL are bound to a keyspace (tables, user-defined types, functions, ...) and the current keyspace is the
-default keyspace used when those objects are referred without a fully-qualified name (that is, without being prefixed a
-keyspace name). A ``USE`` statement simply takes the keyspace to use as current as argument:
-
-.. productionlist::
- use_statement: USE `keyspace_name`
-
-.. _alter-keyspace-statement:
-
-ALTER KEYSPACE
-^^^^^^^^^^^^^^
-
-An ``ALTER KEYSPACE`` statement allows to modify the options of a keyspace:
-
-.. productionlist::
- alter_keyspace_statement: ALTER KEYSPACE `keyspace_name` WITH `options`
-
-For instance::
-
- ALTER KEYSPACE Excelsior
- WITH replication = {\u2019class\u2019: \u2018SimpleStrategy\u2019, \u2018replication_factor\u2019 : 4};
-
-The supported options are the same than for :ref:`creating a keyspace <create-keyspace-options>`.
-
-.. _drop-keyspace-statement:
-
-DROP KEYSPACE
-^^^^^^^^^^^^^
-
-Dropping a keyspace can be done using the ``DROP KEYSPACE`` statement:
-
-.. productionlist::
- drop_keyspace_statement: DROP KEYSPACE [ IF EXISTS ] `keyspace_name`
-
-For instance::
-
- DROP KEYSPACE Excelsior;
-
-Dropping a keyspace results in the immediate, irreversible removal of that keyspace, including all the tables, UTD and
-functions in it, and all the data contained in those tables.
-
-If the keyspace does not exists, the statement will return an error, unless ``IF EXISTS`` is used in which case the
-operation is a no-op.
-
-.. _create-table-statement:
-
-CREATE TABLE
-^^^^^^^^^^^^
-
-Creating a new table uses the ``CREATE TABLE`` statement:
-
-.. productionlist::
- create_table_statement: CREATE TABLE [ IF NOT EXISTS ] `table_name`
- : '('
- : `column_definition`
- : ( ',' `column_definition` )*
- : [ ',' PRIMARY KEY '(' `primary_key` ')' ]
- : ')' [ WITH `table_options` ]
- column_definition: `identifier` `cql_type` [ STATIC ] [ PRIMARY KEY]
- primary_key: `partition_key` [ ',' `clustering_columns` ]
- partition_key: `identifier`
- : | '(' `identifier` ( ',' `identifier` )* ')'
- clustering_columns: `identifier` ( ',' `identifier` )*
- table_options: COMPACT STORAGE [ AND `table_options` ]
- : | CLUSTERING ORDER BY '(' `clustering_order` ')' [ AND `table_options` ]
- : | `options`
- clustering_order: `identifier` (ASC | DESC) ( ',' `identifier` (ASC | DESC) )*
-
-For instance::
-
- CREATE TABLE monkeySpecies (
- species text PRIMARY KEY,
- common_name text,
- population varint,
- average_size int
- ) WITH comment=\u2018Important biological records\u2019
- AND read_repair_chance = 1.0;
-
- CREATE TABLE timeline (
- userid uuid,
- posted_month int,
- posted_time uuid,
- body text,
- posted_by text,
- PRIMARY KEY (userid, posted_month, posted_time)
- ) WITH compaction = { \u2018class\u2019 : \u2018LeveledCompactionStrategy\u2019 };
-
- CREATE TABLE loads (
- machine inet,
- cpu int,
- mtime timeuuid,
- load float,
- PRIMARY KEY ((machine, cpu), mtime)
- ) WITH CLUSTERING ORDER BY (mtime DESC);
-
-A CQL table has a name and is composed of a set of *rows*. Creating a table amounts to defining which :ref:`columns
-<column-definition>` the rows will be composed, which of those columns compose the :ref:`primary key <primary-key>`, as
-well as optional :ref:`options <create-table-options>` for the table.
-
-Attempting to create an already existing table will return an error unless the ``IF NOT EXISTS`` directive is used. If
-it is used, the statement will be a no-op if the table already exists.
-
-
-.. _column-definition:
-
-Column definitions
-~~~~~~~~~~~~~~~~~~
-
-Every rows in a CQL table has a set of predefined columns defined at the time of the table creation (or added later
-using an :ref:`alter statement<alter-table-statement>`).
-
-A :token:`column_definition` is primarily comprised of the name of the column defined and it's :ref:`type <data-types>`,
-which restrict which values are accepted for that column. Additionally, a column definition can have the following
-modifiers:
-
-``STATIC``
- it declares the column as being a :ref:`static column <static-columns>`.
-
-``PRIMARY KEY``
- it declares the column as being the sole component of the :ref:`primary key <primary-key>` of the table.
-
-.. _static-columns:
-
-Static columns
-``````````````
-Some columns can be declared as ``STATIC`` in a table definition. A column that is static will be \u201cshared\u201d by all the
-rows belonging to the same partition (having the same :ref:`partition key <partition-key>`). For instance::
-
- CREATE TABLE t (
- pk int,
- t int,
- v text,
- s text static,
- PRIMARY KEY (pk, t)
- );
-
- INSERT INTO t (pk, t, v, s) VALUES (0, 0, 'val0', 'static0');
- INSERT INTO t (pk, t, v, s) VALUES (0, 1, 'val1', 'static1');
-
- SELECT * FROM t;
- pk | t | v | s
- ----+---+--------+-----------
- 0 | 0 | 'val0' | 'static1'
- 0 | 1 | 'val1' | 'static1'
-
-As can be seen, the ``s`` value is the same (``static1``) for both of the row in the partition (the partition key in
-that example being ``pk``, both rows are in that same partition): the 2nd insertion has overridden the value for ``s``.
-
-The use of static columns as the following restrictions:
-
-- tables with the ``COMPACT STORAGE`` option (see below) cannot use them.
-- a table without clustering columns cannot have static columns (in a table without clustering columns, every partition
- has only one row, and so every column is inherently static).
-- only non ``PRIMARY KEY`` columns can be static.
-
-.. _primary-key:
-
-The Primary key
-~~~~~~~~~~~~~~~
-
-Within a table, a row is uniquely identified by its ``PRIMARY KEY``, and hence all table **must** define a PRIMARY KEY
-(and only one). A ``PRIMARY KEY`` definition is composed of one or more of the columns defined in the table.
-Syntactically, the primary key is defined the keywords ``PRIMARY KEY`` followed by comma-separated list of the column
-names composing it within parenthesis, but if the primary key has only one column, one can alternatively follow that
-column definition by the ``PRIMARY KEY`` keywords. The order of the columns in the primary key definition matter.
-
-A CQL primary key is composed of 2 parts:
-
-- the :ref:`partition key <partition-key>` part. It is the first component of the primary key definition. It can be a
- single column or, using additional parenthesis, can be multiple columns. A table always have at least a partition key,
- the smallest possible table definition is::
-
- CREATE TABLE t (k text PRIMARY KEY);
-
-- the :ref:`clustering columns <clustering-columns>`. Those are the columns after the first component of the primary key
- definition, and the order of those columns define the *clustering order*.
-
-Some example of primary key definition are:
-
-- ``PRIMARY KEY (a)``: ``a`` is the partition key and there is no clustering columns.
-- ``PRIMARY KEY (a, b, c)`` : ``a`` is the partition key and ``b`` and ``c`` are the clustering columns.
-- ``PRIMARY KEY ((a, b), c)`` : ``a`` and ``b`` compose the partition key (this is often called a *composite* partition
- key) and ``c`` is the clustering column.
-
-
-.. _partition-key:
-
-The partition key
-`````````````````
-
-Within a table, CQL defines the notion of a *partition*. A partition is simply the set of rows that share the same value
-for their partition key. Note that if the partition key is composed of multiple columns, then rows belong to the same
-partition only they have the same values for all those partition key column. So for instance, given the following table
-definition and content::
-
- CREATE TABLE t (
- a int,
- b int,
- c int,
- d int,
- PRIMARY KEY ((a, b), c, d)
- );
-
- SELECT * FROM t;
- a | b | c | d
- ---+---+---+---
- 0 | 0 | 0 | 0 // row 1
- 0 | 0 | 1 | 1 // row 2
- 0 | 1 | 2 | 2 // row 3
- 0 | 1 | 3 | 3 // row 4
- 1 | 1 | 4 | 4 // row 5
-
-``row 1`` and ``row 2`` are in the same partition, ``row 3`` and ``row 4`` are also in the same partition (but a
-different one) and ``row 5`` is in yet another partition.
-
-Note that a table always has a partition key, and that if the table has no :ref:`clustering columns
-<clustering-columns>`, then every partition of that table is only comprised of a single row (since the primary key
-uniquely identifies rows and the primary key is equal to the partition key if there is no clustering columns).
-
-The most important property of partition is that all the rows belonging to the same partition are guarantee to be stored
-on the same set of replica nodes. In other words, the partition key of a table defines which of the rows will be
-localized together in the Cluster, and it is thus important to choose your partition key wisely so that rows that needs
-to be fetch together are in the same partition (so that querying those rows together require contacting a minimum of
-nodes).
-
-Please note however that there is a flip-side to this guarantee: as all rows sharing a partition key are guaranteed to
-be stored on the same set of replica node, a partition key that groups too much data can create a hotspot.
-
-Another useful property of a partition is that when writing data, all the updates belonging to a single partition are
-done *atomically* and in *isolation*, which is not the case across partitions.
-
-The proper choice of the partition key and clustering columns for a table is probably one of the most important aspect
-of data modeling in Cassandra, and it largely impact which queries can be performed, and how efficiently they are.
-
-
-.. _clustering-columns:
-
-The clustering columns
-``````````````````````
-
-The clustering columns of a table defines the clustering order for the partition of that table. For a given
-:ref:`partition <partition-key>`, all the rows are physically ordered inside Cassandra by that clustering order. For
-instance, given::
-
- CREATE TABLE t (
- a int,
- b int,
- c int,
- PRIMARY KEY (a, c, d)
- );
-
- SELECT * FROM t;
- a | b | c
- ---+---+---
- 0 | 0 | 4 // row 1
- 0 | 1 | 9 // row 2
- 0 | 2 | 2 // row 3
- 0 | 3 | 3 // row 4
-
-then the rows (which all belong to the same partition) are all stored internally in the order of the values of their
-``b`` column (the order they are displayed above). So where the partition key of the table allows to group rows on the
-same replica set, the clustering columns controls how those rows are stored on the replica. That sorting allows the
-retrieval of a range of rows within a partition (for instance, in the example above, ``SELECT * FROM t WHERE a = 0 AND b
-> 1 and b <= 3``) very efficient.
-
-
-.. _create-table-options
-
-Table options
-~~~~~~~~~~~~~
-
-A CQL table has a number of options that can be set at creation (and, for most of them, :ref:`altered
-<alter-table-statement>` later). These options are specified after the ``WITH`` keyword.
-
-Amongst those options, two important ones cannot be changed after creation and influence which queries can be done
-against the table: the ``COMPACT STORAGE`` option and the ``CLUSTERING ORDER`` option. Those, as well as the other
-options of a table are described in the following sections.
-
-.. _compact-storage:
-
-Compact tables
-``````````````
-
-.. warning:: Since Cassandra 3.0, compact tables have the exact same layout internally than non compact ones (for the
- same schema obviously), and declaring a table compact **only** creates artificial limitations on the table definition
- and usage that are necessary to ensure backward compatibility with the deprecated Thrift API. And as ``COMPACT
- STORAGE`` cannot, as of Cassandra |3.8|, be removed, it is strongly discouraged to create new table with the
- ``COMPACT STORAGE`` option.
-
-A *compact* table is one defined with the ``COMPACT STORAGE`` option. This option is mainly targeted towards backward
-compatibility for definitions created before CQL version 3 (see `www.datastax.com/dev/blog/thrift-to-cql3
-<http://www.datastax.com/dev/blog/thrift-to-cql3>`__ for more details) and shouldn't be used for new tables. Declaring a
-table with this option creates limitations for the table which are largely arbitrary but necessary for backward
-compatibility with the (deprecated) Thrift API. Amongst those limitation:
-
-- a compact table cannot use collections nor static columns.
-- if a compact table has at least one clustering column, then it must have *exactly* one column outside of the primary
- key ones. This imply you cannot add or remove columns after creation in particular.
-- a compact table is limited in the indexes it can create, and no materialized view can be created on it.
-
-.. _clustering-order:
-
-Reversing the clustering order
-``````````````````````````````
-
-The clustering order of a table is defined by the :ref:`clustering columns <clustering-columns>` of that table. By
-default, that ordering is based on natural order of those clustering order, but the ``CLUSTERING ORDER`` allows to
-change that clustering order to use the *reverse* natural order for some (potentially all) of the columns.
-
-The ``CLUSTERING ORDER`` option takes the comma-separated list of the clustering column, each with a ``ASC`` (for
-*ascendant*, e.g. the natural order) or ``DESC`` (for *descendant*, e.g. the reverse natural order). Note in particular
-that the default (if the ``CLUSTERING ORDER`` option is not used) is strictly equivalent to using the option with all
-clustering columns using the ``ASC`` modifier.
-
-Note that this option is basically a hint for the storage engine to change the order in which it stores the row but it
-has 3 visible consequences:
-
-# it limits which ``ORDER BY`` clause are allowed for :ref:`selects <select-statement>` on that table. You can only
- order results by the clustering order or the reverse clustering order. Meaning that if a table has 2 clustering column
- ``a`` and ``b`` and you defined ``WITH CLUSTERING ORDER (a DESC, b ASC)``, then in queries you will be allowed to use
- ``ORDER BY (a DESC, b ASC)`` and (reverse clustering order) ``ORDER BY (a ASC, b DESC)`` but **not** ``ORDER BY (a
- ASC, b ASC)`` (nor ``ORDER BY (a DESC, b DESC)``).
-# it also change the default order of results when queried (if no ``ORDER BY`` is provided). Results are always returned
- in clustering order (within a partition).
-# it has a small performance impact on some queries as queries in reverse clustering order are slower than the one in
- forward clustering order. In practice, this means that if you plan on querying mostly in the reverse natural order of
- your columns (which is common with time series for instance where you often want data from the newest to the oldest),
- it is an optimization to declare a descending clustering order.
-
-.. _create-table-general-options:
-
-Other table options
-```````````````````
-
-.. todo:: review (misses cdc if nothing else) and link to proper categories when appropriate (compaction for instance)
-
-A table supports the following options:
-
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| option | kind | default | description |
-+==================================+============+===============+=================================================================================================================================================================================================================================+
-| ``comment`` | *simple* | none | A free-form, human-readable comment. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``read_repair_chance`` | *simple* | 0.1 | The probability with which to query extra nodes (e.g. more nodes than required by the consistency level) for the purpose of read repairs. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``dclocal_read_repair_chance`` | *simple* | 0 | The probability with which to query extra nodes (e.g. more nodes than required by the consistency level) belonging to the same data center than the read coordinator for the purpose of read repairs. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``gc_grace_seconds`` | *simple* | 864000 | Time to wait before garbage collecting tombstones (deletion markers). |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``bloom_filter_fp_chance`` | *simple* | 0.00075 | The target probability of false positive of the sstable bloom filters. Said bloom filters will be sized to provide the provided probability (thus lowering this value impact the size of bloom filters in-memory and on-disk) |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``default_time_to_live`` | *simple* | 0 | The default expiration time (\u201cTTL\u201d) in seconds for a table. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``compaction`` | *map* | *see below* | Compaction options, see \u201cbelow\u201d:#compactionOptions. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``compression`` | *map* | *see below* | Compression options, see \u201cbelow\u201d:#compressionOptions. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``caching`` | *map* | *see below* | Caching options, see \u201cbelow\u201d:#cachingOptions. |
-+----------------------------------+------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-Compaction options
-##################
-
-The ``compaction`` property must at least define the ``'class'``
-sub-option, that defines the compaction strategy class to use. The
-default supported class are ``'SizeTieredCompactionStrategy'``,
-``'LeveledCompactionStrategy'``, ``'DateTieredCompactionStrategy'`` and
-``'TimeWindowCompactionStrategy'``. Custom strategy can be provided by
-specifying the full class name as a `string constant <#constants>`__.
-The rest of the sub-options depends on the chosen class. The sub-options
-supported by the default classes are:
-
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| option | supported compaction strategy | default | description |
-+======================================+=================================+================+========================================================================================================================================================================================================================================================================================================================================+
-| ``enabled`` | *all* | true | A boolean denoting whether compaction should be enabled or not. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``tombstone_threshold`` | *all* | 0.2 | A ratio such that if a sstable has more than this ratio of gcable tombstones over all contained columns, the sstable will be compacted (with no other sstables) for the purpose of purging those tombstones. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``tombstone_compaction_interval`` | *all* | 1 day | The minimum time to wait after an sstable creation time before considering it for \u201ctombstone compaction\u201d, where \u201ctombstone compaction\u201d is the compaction triggered if the sstable has more gcable tombstones than ``tombstone_threshold``. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``unchecked_tombstone_compaction`` | *all* | false | Setting this to true enables more aggressive tombstone compactions - single sstable tombstone compactions will run without checking how likely it is that they will be successful. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``min_sstable_size`` | SizeTieredCompactionStrategy | 50MB | The size tiered strategy groups SSTables to compact in buckets. A bucket groups SSTables that differs from less than 50% in size. However, for small sizes, this would result in a bucketing that is too fine grained. ``min_sstable_size`` defines a size threshold (in bytes) below which all SSTables belong to one unique bucket |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``min_threshold`` | SizeTieredCompactionStrategy | 4 | Minimum number of SSTables needed to start a minor compaction. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``max_threshold`` | SizeTieredCompactionStrategy | 32 | Maximum number of SSTables processed by one minor compaction. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``bucket_low`` | SizeTieredCompactionStrategy | 0.5 | Size tiered consider sstables to be within the same bucket if their size is within [average\_size \* ``bucket_low``, average\_size \* ``bucket_high`` ] (i.e the default groups sstable whose sizes diverges by at most 50%) |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``bucket_high`` | SizeTieredCompactionStrategy | 1.5 | Size tiered consider sstables to be within the same bucket if their size is within [average\_size \* ``bucket_low``, average\_size \* ``bucket_high`` ] (i.e the default groups sstable whose sizes diverges by at most 50%). |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``sstable_size_in_mb`` | LeveledCompactionStrategy | 5MB | The target size (in MB) for sstables in the leveled strategy. Note that while sstable sizes should stay less or equal to ``sstable_size_in_mb``, it is possible to exceptionally have a larger sstable as during compaction, data for a given partition key are never split into 2 sstables |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``timestamp_resolution`` | DateTieredCompactionStrategy | MICROSECONDS | The timestamp resolution used when inserting data, could be MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) - don\u2019t change this unless you do mutations with USING TIMESTAMP (or equivalent directly in the client) |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``base_time_seconds`` | DateTieredCompactionStrategy | 60 | The base size of the time windows. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``max_sstable_age_days`` | DateTieredCompactionStrategy | 365 | SSTables only containing data that is older than this will never be compacted. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``timestamp_resolution`` | TimeWindowCompactionStrategy | MICROSECONDS | The timestamp resolution used when inserting data, could be MILLISECONDS, MICROSECONDS etc (should be understandable by Java TimeUnit) - don\u2019t change this unless you do mutations with USING TIMESTAMP (or equivalent directly in the client) |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``compaction_window_unit`` | TimeWindowCompactionStrategy | DAYS | The Java TimeUnit used for the window size, set in conjunction with ``compaction_window_size``. Must be one of DAYS, HOURS, MINUTES |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``compaction_window_size`` | TimeWindowCompactionStrategy | 1 | The number of ``compaction_window_unit`` units that make up a time window. |
-+--------------------------------------+---------------------------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-Compression options
-###################
-
-For the ``compression`` property, the following sub-options are
-available:
-
-+------------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| option | default | description |
-+========================+=================+=======================================================================================================================================================================================================================================================================================================================================================================================================================+
-| ``class`` | LZ4Compressor | The compression algorithm to use. Default compressor are: LZ4Compressor, SnappyCompressor and DeflateCompressor. Use ``'enabled' : false`` to disable compression. Custom compressor can be provided by specifying the full class name as a \u201cstring constant\u201d:#constants. |
-+------------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``enabled`` | true | By default compression is enabled. To disable it, set ``enabled`` to ``false`` |
-+------------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-|`` chunk_length_in_kb`` | 64KB | On disk SSTables are compressed by block (to allow random reads). This defines the size (in KB) of said block. Bigger values may improve the compression rate, but increases the minimum size of data to be read from disk for a read |
-+------------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``crc_check_chance`` | 1.0 | When compression is enabled, each compressed block includes a checksum of that block for the purpose of detecting disk bitrot and avoiding the propagation of corruption to other replica. This option defines the probability with which those checksums are checked during read. By default they are always checked. Set to 0 to disable checksum checking and to 0.5 for instance to check them every other read |
-+------------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-Caching options
-###############
-
-For the ``caching`` property, the following sub-options are available:
-
-+--------------------------+-----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| option | default | description |
-+==========================+===========+============================================================================================================================================================================================================================================================================+
-| ``keys`` | ALL | Whether to cache keys (\u201ckey cache\u201d) for this table. Valid values are: ``ALL`` and ``NONE``. |
-+--------------------------+-----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``rows_per_partition`` | NONE | The amount of rows to cache per partition (\u201crow cache\u201d). If an integer ``n`` is specified, the first ``n`` queried rows of a partition will be cached. Other possible options are ``ALL``, to cache all rows of a queried partition, or ``NONE`` to disable row caching. |
-+--------------------------+-----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-Other considerations:
-#####################
-
-- When `inserting <#insertStmt>`__ / `updating <#updateStmt>`__ a given
- row, not all columns needs to be defined (except for those part of
- the key), and missing columns occupy no space on disk. Furthermore,
- adding new columns (see \ ``ALTER TABLE``\ ) is a constant time
- operation. There is thus no need to try to anticipate future usage
- (or to cry when you haven\u2019t) when creating a table.
-
-ALTER TABLE
-^^^^^^^^^^^
-
-Altering an existing table uses the ``ALTER TABLE`` statement:
-
-.. productionlist::
- alter_table_statement: ALTER TABLE `table_name` `alter_table_instruction`
- alter_table_instruction: ALTER `identifier` TYPE `cql_type`
- : | ADD `identifier` `cql_type` ( ',' `identifier` `cql_type` )*
- : | DROP `identifier` ( `identifier` )*
- : | WITH `options`
-
-For instance::
-
- ALTER TABLE addamsFamily ALTER lastKnownLocation TYPE uuid;
-
- ALTER TABLE addamsFamily ADD gravesite varchar;
-
- ALTER TABLE addamsFamily
- WITH comment = \u2018A most excellent and useful table\u2019
- AND read_repair_chance = 0.2;
-
-The ``ALTER TABLE`` statement can:
-
-- Change the type of one of the column in the table (through the ``ALTER`` instruction). Note that the type of a column
- cannot be changed arbitrarily. The change of type should be such that any value of the previous type should be a valid
- value of the new type. Further, for :ref:`clustering columns <clustering-columns>` and columns on which a secondary
- index is defined, the new type must sort values in the same way the previous type does. See the :ref:`type
- compatibility table <alter-table-type-compatibility>` below for detail on which type changes are accepted.
-- Add new column(s) to the table (through the ``ADD`` instruction). Note that the primary key of a table cannot be
- changed and thus newly added column will, by extension, never be part of the primary key. Also note that :ref:`compact
- tables <compact-tables>` have restrictions regarding column addition.
-- Remove column(s) from the table. This drops both the column and all its content, but note that while the column
- becomes immediately unavailable, its content is only removed lazily during compaction. Please also see the warnings
- below.
-- Change some of the table options (through the ``WITH`` instruction). The :ref:`supported options
- <create-table-options>` are the same that when creating a table (outside of ``COMPACT STORAGE`` and ``CLUSTERING
- ORDER`` that cannot be changed after creation). Note that setting any ``compaction`` sub-options has the effect of
- erasing all previous ``compaction`` options, so you need to re-specify all the sub-options if you want to keep them.
- The same note applies to the set of ``compression`` sub-options.
-
-.. warning:: Dropping a column assumes that the timestamps used for the value of this column are "real" timestamp in
- microseconds. Using "real" timestamps in microseconds is the default is and is **strongly** recommended but as
- Cassandra allows the client to provide any timestamp on any table it is theoretically possible to use another
- convention. Please be aware that if you do so, dropping a column will not work correctly.
-
-.. warning:: Once a column is dropped, it is allowed to re-add a column with the same name than the dropped one
- **unless* the type of the dropped column was a (non-frozen) column (due to an internal technical limitation).
-
-.. _alter-table-type-compatibility:
-
-CQL type compatibility:
-~~~~~~~~~~~~~~~~~~~~~~~
-
-CQL data types may be converted only as the following table.
-
-+-------------------------------------------------------+--------------------+
-| Existing type | Can be altered to: |
-+=======================================================+====================+
-| timestamp | bigint |
-+-------------------------------------------------------+--------------------+
-| ascii, bigint, boolean, date, decimal, double, float, | blob |
-| inet, int, smallint, text, time, timestamp, timeuuid, | |
-| tinyint, uuid, varchar, varint | |
-+-------------------------------------------------------+--------------------+
-| int | date |
-+-------------------------------------------------------+--------------------+
-| ascii, varchar | text |
-+-------------------------------------------------------+--------------------+
-| bigint | time |
-+-------------------------------------------------------+--------------------+
-| bigint | timestamp |
-+-------------------------------------------------------+--------------------+
-| timeuuid | uuid |
-+-------------------------------------------------------+--------------------+
-| ascii, text | varchar |
-+-------------------------------------------------------+--------------------+
-| bigint, int, timestamp | varint |
-+-------------------------------------------------------+--------------------+
-
-Clustering columns have stricter requirements, only the following conversions are allowed:
-
-+------------------------+-------------------+
-| Existing type | Can be altered to |
-+========================+===================+
-| ascii, text, varchar | blob |
-+------------------------+-------------------+
-| ascii, varchar | text |
-+-----------------------
<TRUNCATED>