[
https://issues.apache.org/jira/browse/CASSANDRA-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985011#action_12985011
]
Eric Evans commented on CASSANDRA-2025:
---------------------------------------
bq. 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 WITH's and such and that is much more wordy and
would be really hard to craft in the general sense.
First off, let's put this in perspective and make sure we're not
over-{thinking,engineering}. The "problem", such as it is right now, is one
string map, one-level deep, in one place. That is to say, this is the
exception, rather than rule.
And, to be fair, I offered a suggestion that was free of ANDs and WITHs. :)
bq. So what part of it is "Not Good"? too many special characters? too
confusing? JSON uses this general notation right?
It's baking a data-interchange format into a DSL that is supposed to be
expressive and easy to grok/type. For every statement in the language, you
could easily replace the entire thing with JSON, (not recommending that either).
bq. I am assuming the depth in select you speak of would be used for the
addition of "super-columns" and ultimately arbitrary depth "slices"?
Yes, but this is accomplished by compositing names in a flat namespace, so I
think you could make the argument that it's more intuitive to look at it that
way. We should also be optimizing for the common case (this isn't it), and a
JSON-formatted projection (for example), doesn't do that.
> 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.
