cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2025) generalized way of expressing hierarchical values
Date Sat, 22 Jan 2011 00:10:43 GMT


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:
>             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