Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <17225611.119231295652523816.JavaMail.jira@thor>
Date: Fri, 21 Jan 2011 18:28:43 -0500 (EST)
From: "Eric Evans (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Updated: (CASSANDRA-2025) generalized way of expressing
 hierarchical values
In-Reply-To: <1244121.114291295639864500.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.