Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <13147409.119051295652163927.JavaMail.jira@thor>
Date: Fri, 21 Jan 2011 18:22:43 -0500 (EST)
From: "Eric Evans (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (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:comment-tabpanel&focusedCommentId=12984993#action_12984993 ] 

Eric Evans commented on CASSANDRA-2025:
---------------------------------------

That is similar to how the CLI handles this case, and I'm not a huge fan. Plus, if it's important to come up with something that works for the compound column example, then that would result in something like the following (which is Not Good IMO):

{code:style=SQL}
SELECT {"a": {"b": {"c": "foo"}}}  FROM ...
{code}

> 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}
> 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?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.