[
https://issues.apache.org/jira/browse/CASSANDRA-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2025:
----------------------------------
Description:
While hashing out {{CREATE KEYSPACE}}, it became obvious that we needed a
syntax for expressing hierarchical values. Properties like
{{replication_factor}} can be expressed simply using keyword arguments like
({{replication_factor = 3}}), but {{strategy_options}} is a map of strings.
The solution I took in CASSANDRA-1709 was to dot-delimit "map name" and option
key, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options.DC1 = "1" ...
{code}
This led me to wonder if this was a general enough approach for any future
cases that might come up. One example might be compound/composite column
names. Dot-delimiting is a bad choice here since it rules out ever introducing
a float literal.
One suggestion would be to colon-delimit, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options:DC1 = "1" ...
{code}
Or in the case of composite column names:
{code:style=SQL}
SELECT columnA:columnB,column1:column2 FROM Standard2 USING CONSISTENCY.QUORUM
WHERE KEY = key;
UPDATE Standard2 SET columnA:columnB = valueC, column1:column2 = value3 WHERE
KEY = key;
{code}
As an aside, this also led me to the conclusion that {{CONSISTENCY.<LEVEL>}} is
probably a bad choice for consistency level specification. It mirrors the
underlying enum for no good reason and should probably be changed to
{{CONSISTENCY <LEVEL>}} (i.e. omitting the separator). For example:
{code:style=SQL}
SELECT column FROM Standard2 USING CONSISTENCY QUORUM WHERE KEY = key;
{code}
Thoughts?
*Edit: improved final example*
*Edit: restore final example, create new one (gah).*
was:
While hashing out {{CREATE KEYSPACE}}, it became obvious that we needed a
syntax for expressing hierarchical values. Properties like
{{replication_factor}} can be expressed simply using keyword arguments like
({{replication_factor = 3}}), but {{strategy_options}} is a map of strings.
The solution I took in CASSANDRA-1709 was to dot-delimit "map name" and option
key, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options.DC1 = "1" ...
{code}
This led me to wonder if this was a general enough approach for any future
cases that might come up. One example might be compound/composite column
names. Dot-delimiting is a bad choice here since it rules out ever introducing
a float literal.
One suggestion would be to colon-delimit, so for example:
{code:style=SQL}
CREATE KEYSPACE keyspace WITH ... AND strategy_options:DC1 = "1" ...
{code}
As an aside, this also led me to the conclusion that {{CONSISTENCY.<LEVEL>}} is
probably a bad choice for consistency level specification. It mirrors the
underlying enum for no good reason and should probably be changed to
{{CONSISTENCY <LEVEL>}} (i.e. omitting the separator). For example:
{code:style=SQL}
SELECT columnA:columnB,column1:column2 FROM Standard2 USING CONSISTENCY QUORUM
WHERE KEY = key;
UPDATE Standard2 SET columnA:columnB = valueC, column1:column2 = value3 WHERE
KEY = key;
{code}
Thoughts?
*Edit: improved final example*
> generalized way of expressing hierarchical values
> -------------------------------------------------
>
> Key: CASSANDRA-2025
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2025
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Eric Evans
> Assignee: Eric Evans
> Priority: Minor
> Fix For: 0.8
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> While hashing out {{CREATE KEYSPACE}}, it became obvious that we needed a
> syntax for expressing hierarchical values. Properties like
> {{replication_factor}} can be expressed simply using keyword arguments like
> ({{replication_factor = 3}}), but {{strategy_options}} is a map of strings.
> The solution I took in CASSANDRA-1709 was to dot-delimit "map name" and
> option key, so for example:
> {code:style=SQL}
> CREATE KEYSPACE keyspace WITH ... AND strategy_options.DC1 = "1" ...
> {code}
> This led me to wonder if this was a general enough approach for any future
> cases that might come up. One example might be compound/composite column
> names. Dot-delimiting is a bad choice here since it rules out ever
> introducing a float literal.
> One suggestion would be to colon-delimit, so for example:
> {code:style=SQL}
> CREATE KEYSPACE keyspace WITH ... AND strategy_options:DC1 = "1" ...
> {code}
> Or in the case of composite column names:
> {code:style=SQL}
> SELECT columnA:columnB,column1:column2 FROM Standard2 USING
> CONSISTENCY.QUORUM WHERE KEY = key;
> UPDATE Standard2 SET columnA:columnB = valueC, column1:column2 = value3 WHERE
> KEY = key;
> {code}
> As an aside, this also led me to the conclusion that {{CONSISTENCY.<LEVEL>}}
> is probably a bad choice for consistency level specification. It mirrors the
> underlying enum for no good reason and should probably be changed to
> {{CONSISTENCY <LEVEL>}} (i.e. omitting the separator). For example:
> {code:style=SQL}
> SELECT column FROM Standard2 USING CONSISTENCY QUORUM WHERE KEY = key;
> {code}
> Thoughts?
> *Edit: improved final example*
> *Edit: restore final example, create new one (gah).*
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
