[
https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985004#action_12985004
]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
bq. For consistency you might consider making the utf-8 terms a function like
uuid and timeuuid.
Thought about that. It's 5 extra characters for a fairly common term (that
could really add up in say a batch update), and to me it doesn't seem that much
more expressive (but maybe that's my Python background talking). As far as
consistency goes, utf8 is closer to the other literals than the more complex
UUID types (they're basically just a variant on strings)
bq. How about a Date function as well?
That seems like it would cause confusion with timeuuid() (which is capable of
greater resolution). I could see maybe aliasing date() to timeuuid() though.
> 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
> Fix For: 0.8
>
> 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.
-
You can reply to this email to add a comment to the issue online.
