[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002396#comment-13002396
]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
The following reboot is the result of a discussion between Gary Dusbabek,
Jonathan Ellis, and myself (any errors or misunderstandings are my fault).
h2. Revised definitions (+ semantics)
h3. String
Anything between quotes, _or_ any unquoted alnum values that begins with a
letter.
Examples:
{code:style=SQL}
SELECT "0day" FROM cf;
SELECT B_day FROM cf;
UPDATE cf SET "value-low" = "14%" WHERE KEY = "@skinny";
UPDATE cf SET foo = bar WHERE KEY = baz;
{code}
h3. Integer
An undecorated numeric literal. How the term is converted node-side is
determined by the comparator/validator in use. For example, {{100}} could be
converted to a 4-byte integer or an 8-byte long depending on whether the
comparator/validator was an {{IntegerType}} or {{LongType}} respectively.
Examples:
{code:style=SQL}
SELECT 10..100 FROM cf WHERE KEY = "key";
UPDATE cf SET 1000 = "thousand", 100 = "hundred" WHERE KEY = "key";
{code}
h3. UUID
A UUID formated as a hexidecimal-hyphenated string (i.e.
{{b137dd10-45b6-11e0-8955-00247ee1f924}}).
Examples:
{code:style=SQL}
SELECT f1fa6c22-45b7-11e0-8955-00247ee1f924 FROM cf WHERE KEY = key;
UPDATE cf SET 0ceb632e-45b8-11e0-8955-00247ee1f924 = 9 WHERE KEY = key;
{code}
As a special-case, when the comparator/validator is TimeUUIDType, a quoted
string literal can be used to supply a parse-able timestamp (currently most
ISO8601 variants).
{code:style=SQL}
SELECT "2011-01-01".."2011-02-01" FROM cf WHERE KEY = key;
{code}
_Note: it doesn't make sense to try to query by-column using a timestamp like
this, because date-time is only one component of a type 1 UUID. The docs will
need to be clear about this._
h3. UTF-8
A double-quoted string literal that is prefixed with a "u" to indicate 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}
_This one is iffy. Consensus seems to be that the UTF8 charset should
implicitly be used in the conversion to bytes when comparator/validator is
UTF8Type. If that's the case, then the only time where this term would do
anything useful would be for storing UTF8 where comparator/validator is
BytesType. That seems corner-case enough for me to warrant leaving it out
entirely._
----
One point of contention during the discussion that spawned this reboot was type
inference. What's proposed above adds some inference, (namely for unicode,
decimal values, and some UUID cases), but I'm going to make one more attempt at
stopping it there. I'm nothing if not persistent, right? :)
For example, Least Surprise says that {{"10"}} and {{10}} differ in that one is
explicitly a string, so converting it to a numeric type with a decimal value of
10 (still) seems wrong to me. I'd prefer to raise an exception for such
mismatches, which also seems like a good way of protecting users from a whole
class of bugs.
I'm also continuing to have a hard time accepting that different rules should
exist (syntax and semantics) for column names and values. The general argument
for SQL parity is a strong one, and I'm trying to be convinced on this issue,
(honest), but I keep coming back to the notion that SQL column names are not
typed, and that forcing that distinction on Cassandra seems contrived.
> 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
