You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Eric Evans (JIRA)" <ji...@apache.org> on 2011/01/21 22:31:43 UTC
[jira] Created: (CASSANDRA-2027) term definitions
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
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.
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Attachment: (was: v1-0003-remove-JUG-jar-and-references.txt)
> 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
>
> Attachments: v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002902#comment-13002902 ]
Gary Dusbabek commented on CASSANDRA-2027:
------------------------------------------
bq. That seems corner-case enough for me to warrant leaving it out entirely.
I'm for leaving it out then.
bq. I'm also continuing to have a hard time accepting that different rules should exist (syntax and semantics) for column names and values.
I favor not requiring quotes on right-values when the type can be inferred (and throwing exception when right-values are quoted and the validator expects non-quoted). This would mean the same rules for cols and vals, no?
Also, for utf8, we should make sure we support specifying characters in the \uXXXX format.
> 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
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Attachment: v1-0003-remove-JUG-jar-and-references.txt
v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt
v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt
> 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
>
> Attachments: v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt, v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt, v1-0003-remove-JUG-jar-and-references.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002472#comment-13002472 ]
Jonathan Ellis commented on CASSANDRA-2027:
-------------------------------------------
bq. That seems corner-case enough for me to warrant leaving it out entirely
No strong feelings here either way.
bq. I'm also continuing to have a hard time accepting that different rules should exist (syntax and semantics) for column names and values
I feel strongly about this b/c forcing quoting of "normal" column names is going to needlessly give people the impression that "this is a low-quality implementation."
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006648#comment-13006648 ]
Hudson commented on CASSANDRA-2027:
-----------------------------------
Integrated in Cassandra #776 (See [https://hudson.apache.org/hudson/job/Cassandra/776/])
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984989#action_12984989 ]
Rick Shaw commented on CASSANDRA-2027:
--------------------------------------
For consistency you might consider making the utf-8 terms a function like uuid and timeuuid.
Example:
\\
\\
{code}
SELECT utf8("name") FROM cf;
UPDATE cf SET utf8("name") = utf8("value") WHERE KEY = "key";
{code}
How about a Date function as well?:
{code}
SELECT date("2011-01-21") FROM cf; // default to ISO
SELECT date("2011-01-21T23:10:30.123 -0700", "yyyy-MM-dd'T'HH:mm:ss.SSSZ") FROM cf; // using a formatting string
{code}
\\
\\
This would store the "long" microseconds value on the node side ByteBuffer.
> 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.
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990219#comment-12990219 ]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
The attached patches implement the terms discussed in description.
Any help in reviewing this (before or after commit) would be greatly appreciated, but to avoid creating unnecessary merge/rebase conflicts, I'll probably commit this on Monday if I don't hear anything.
> 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
>
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002790#comment-13002790 ]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
I just fired up a test instance of Postgres to try to get an idea of how some of this looked in practice.
Creating a table with column _named_ "10", with int typed values. Using a numeric literal here does not work (i.e. it must be quoted).
{quote}
test=# CREATE TABLE oneint(10 int);
ERROR: syntax error at or near "10"
LINE 1: CREATE TABLE oneint(10 int);
test=# CREATE TABLE oneint("10" int);
CREATE TABLE
{quote}
Inserting an integer value of 10 into the column named 10. Quoting the value does not work, nor does using a numeric literal for the column name.
{quote}
test=# INSERT INTO oneint ("10") VALUES ("10");
ERROR: column "10" does not exist
LINE 1: INSERT INTO oneint ("10") VALUES ("10");
test=# INSERT INTO oneint (10) VALUES (10);
ERROR: syntax error at or near "10"
LINE 1: INSERT INTO oneint (10) VALUES (10);
test=# INSERT INTO oneint ("10") VALUES (10);
INSERT 0 1
{quote}
Strangely enough though, single quoting the value does work, while single quoting the column name does not.
{quote}
test=# INSERT INTO oneint VALUES ('10');
INSERT 0 1
test=# INSERT INTO oneint ('10') VALUES (10);
ERROR: syntax error at or near "'10'"
LINE 1: INSERT INTO oneint ('10') VALUES (10);
{quote}
But, anything goes for column names in a projection.
{quote}
test=# SELECT "10" FROM oneint;
10
---
10
(1 rows)
test=# SELECT '10' FROM oneint;
?column?
---
10
(1 rows)
test=# SELECT 10 FROM oneint;
?column?
---
10
(1 rows)
{quote}
There may be a method to all of that madness, but it escapes me, and it seems even more convoluted trying to map this to CQL in light of the fact that column names here are string identifiers and values are typed, and both column names and values are typed in Cassandra.
It may also be worth mentioning that I repeated this experiment for MySQL and SQLite (what was handy) with results that were entirely inconsistent with both Postgres and each other.
So like I said, I'm trying to be convinced, but I keep imagining (1) trying to explain to someone the rules governing syntax and semantics and then (2) attempting to answer the question "but why is it like that?". So far it seems the answer to both is SQL, (i.e. "it works the same way as SQL", and "it's that way because SQL is that way). That strikes me as a bad answer to both. It's a bad answer to the How because it's somewhere between a non-answer and not true (depending on whether you're referring to one of the specs, or implementations). It's a bad answer to Why because of the impedance mismatch, because we're far from being SQL compliant otherwise, and because mimicking something broken is broken (for some value of broken, I guess).
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Attachment: (was: v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.txt)
> 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.
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002827#comment-13002827 ]
Jonathan Ellis commented on CASSANDRA-2027:
-------------------------------------------
The SQL standard is, single quotes are for string literals and double quotes are for identifiers that need escaping.
> 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
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Attachment: (was: v1-0002-eliminate-usage-of-JUG-for-UUIDs.txt)
> 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
>
> Attachments: v1-0001-CASSANDRA-2027-o.a.c.utils.UUIDGen-adapted-from-flewto.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Attachment: v1-0005-missed-doc-update-for-utf8-term-type.txt
v1-0004-uuid-term-definitions.txt
v1-0003-system-tests-for-integer-and-utf8-term-types.txt
v1-0002-column-name-validation.txt
v1-0001-CASSANDRA-2027-utf8-and-integer-term-types.txt
> 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
>
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002909#comment-13002909 ]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
bq. I favor not requiring quotes on right-values when the type can be inferred (and throwing exception when right-values are quoted and the validator expects non-quoted). This would mean the same rules for cols and vals, no?
I think so.
In my last dump above, I introduced the unquoted string term type ("...any unquoted alnum values that begins with a letter") and intentionally left out a column name versus value distinction, (since I don't like the idea of special-casing the name). I don't think Jonathan objects to that though.
So I guess it boils down to inferring strings from numbers and vice versa, which I suppose you could argue is a strange line to draw given that we've accepted that we're going to infer string charsets, UUID versions, and long versus int (which is still disappointing to me).
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991586#comment-12991586 ]
Hudson commented on CASSANDRA-2027:
-----------------------------------
Integrated in Cassandra #713 (See [https://hudson.apache.org/hudson/job/Cassandra/713/])
missed doc update for utf8 term type
Patch by eevans for CASSANDRA-2027
uuid term definitions
Patch by eevans for CASSANDRA-2027
system tests for integer and utf8 term types
Patch by eevans for CASSANDRA-2027
column name validation
Patch by eevans for CASSANDRA-2027
utf8 and integer term types
Patch by eevans for CASSANDRA-2027
> 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
>
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002844#comment-13002844 ]
Eric Evans commented on CASSANDRA-2027:
---------------------------------------
bq. The SQL standard is, single quotes are for string literals and double quotes are for identifiers that need escaping.
That sounds right; I think I knew that. You'd sure never suss that out from looking at implementations 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
> 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
[jira] [Resolved] (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans resolved CASSANDRA-2027.
-----------------------------------
Resolution: Fixed
This (meta-)issue is complete.
> 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
[jira] Commented: (CASSANDRA-2027) term definitions
Posted by "Rick Shaw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985008#action_12985008 ]
Rick Shaw commented on CASSANDRA-2027:
--------------------------------------
For keys and for column names I see your point, but for column values, my organization has an enormous amount of data represented as dates and timestamps (of the 8 byte long variety). Improved resolution is not an issue for this type of column value.
> 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.
[jira] Updated: (CASSANDRA-2027) term definitions
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Evans updated CASSANDRA-2027:
----------------------------------
Labels: cql (was: )
> 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