Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 4 Mar 2011 06:40:36 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1602565229.13146.1299220836936.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <21882016.116241295645503807.JavaMail.jira@thor>
Subject: [jira] Commented: (CASSANDRA-2027) term definitions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Ellis commented on CASSANDRA-2027:
-------------------------------------------

Why are we using double quotes instead of standard single?

> term definitions
> ----------------
>
>                 Key: CASSANDRA-2027
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2027
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>    Affects Versions: 0.8
>            Reporter: Eric Evans
>            Assignee: Eric Evans
>            Priority: Minor
>              Labels: cql
>             Fix For: 0.8
>
>         Attachments: v1-0001-CASSANDRA-2027-utf8-and-integer-term-types.txt, v1-0002-column-name-validation.txt, v1-0003-system-tests-for-integer-and-utf8-term-types.txt, v1-0004-uuid-term-definitions.txt, v1-0005-missed-doc-update-for-utf8-term-type.txt
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> h3. String
> Anything between double-quotes.  Node-side this is just converted to bytes, so it could really be used to represent *any* type so long as it is appropriately encoded.
> Examples:
> {code:style=SQL}
> SELECT "name" FROM cf;
> UPDATE cf SET "name" = "value" WHERE KEY = "key";
> {code}
> h3. UTF-8
> A double-quoted string literal that is prefixed with a "u" to indicated that it should be encoded to bytes using the utf-8 charset node-side.
> Examples:
> {code:style=SQL}
> SELECT u"name" FROM cf;
> UPDATE cf SET u"name" = u"value" WHERE KEY = "key";
> {code}
> h3. Integer
> An undecorated numeric literal, converted to a 4-byte int node-side.
> Examples:
> {code:style=SQL}
> SELECT 10..100 FROM cf WHERE KEY = "key";
> UPDATE cf SET 1000 = "thousand", 100 = "hundred" WHERE KEY = "key";
> {code}
> h3. Long
> A numeric literal suffixed with an "L", converted to an 8-byte long node-side.
> Examples:
> {code:style=SQL}
> SELECT 10L..100L FROM cf WHERE KEY = "key";
> UPDATE cf SET 1000L = "thousand", 100L = "hundred" WHERE KEY = "key";
> {code}
> h3. UUID
> A string-formatted UUID supplied as an "argument" to a ctor/function formated string ({{uuid(<uuid string>)}}).  Node-side this is converted back to the corresponding UUID.
> Examples:
> {code:style=SQL}
> SELECT uuid(5f989e95-ae07-4425-b84a-6876ba106c66) FROM cf WHERE KEY = "key";
> UPDATE cf SET uuid(5621b93d-d3a2-4d22-8a59-bdb93202b6cb)  = "username" WHERE KEY = "key";
> {code}
> h3. TimeUUID (UUID Type 1)
> A string-formatted time-based UUID (type 1) supplied as an "argument" to a ctor/function formated string ({{timeuuid(<uuid string>)}}).  Node-side this is converted back to the corresponding UUID.  In addition to a string-formatted UUID, it should also be possible to supply dates in a variety of formats which will result in a new UUID being created node-side.
> Examples:
> {code:style=SQL}
> SELECT timeuuid(2011-01-01)..timeuuid(2010-01-21) FROM cf WHERE KEY = "key";
> UPDATE cf SET timeuuid(now) = 1000L  WHERE KEY = "key";
> {code}

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira