cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2025) generalized way of expressing hierarchical values
Date Fri, 21 Jan 2011 23:34:45 GMT


Rick Shaw commented on CASSANDRA-2025:

Well some "device" has to be introduced to handle depth, and there are not alot of good choices
other that this. The "brackety" one is concise and at least you can parse it both visibly
and mechanically; the alternate is some "texty" pattern of AND's and WITHS and such and that
is much more wordy and would be really hare to craft in the general sense.

So what part of it is "Not Good"? JSON uses this general notation right? 

I am assuming the depth in select you speak of would be used for the addition of "
super-columns" and ultimately arbitrary depth "slices"?

> generalized way of expressing hierarchical values
> -------------------------------------------------
>                 Key: CASSANDRA-2025
>                 URL:
>             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}
> {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.

View raw message