[ https://issues.apache.org/jira/browse/CASSANDRA-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986493#action_12986493 ]
T Jake Luciani commented on CASSANDRA-2025: ------------------------------------------- . feels the best one option would be to escape them in the case of a float 10\.5.string.foo > 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.