[
https://issues.apache.org/jira/browse/CASSANDRA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928312#action_12928312
]
Eric Evans commented on CASSANDRA-1704:
---------------------------------------
This is definitely better than what I came up with when I was trying to be
as-SQL-as-possible.
bq. Note that a bare "AS" is a SQL keyword legal in column-specification
clauses to change the name in the resultset, so I used MARSHAL AS to
disambiguate. I think this is the weakest part of this proposal and improvement
can probably be made there. (WITH is another possibility – also a SQL keyword,
but a more obscure one, and not AFAIK legal in the column-specification clause
so would be unambiguous. NAMES AS might also work.)
So, what does `MARSHAL AS' do here? Does it tell the node to use a different
comparator for sorting, or is it the expectation that clients would use this to
type the results?
bq. One point of clarification: how does <EXPRESSION> not count as support for
indexes?
Well, mostly I just meant that in general the current implementation didn't
support indexes. Right now, an expression consists of AND'd relations where
the relations compare a term to either KEY or COLUMN. Indexes would just
require allowing a term on the left and right side of the relational operator,
the column name would be the term on the left side.
{code:SQL}
... WHERE KEY > "aaa" AND KEY < "ddd" AND "temperature" > 80 ...
{code}
> CQL reads (aka SELECT)
> ----------------------
>
> Key: CASSANDRA-1704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1704
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Affects Versions: 0.8
> Reporter: Eric Evans
> Priority: Minor
> Fix For: 0.8
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Data access specification and implementation for CQL.
> This corresponds to the following RPC methods:
> * get()
> * get_slice()
> * get_count()
> * multiget_slice()
> * multiget_count()
> * get_range_slices()
> * get_indexed_slices()
> The initial check-in to trunk/ uses a syntax that looks like:
> {code:SQL}
> SELECT (FROM)? <CF> [USING CONSISTENCY.<LVL>] WHERE <EXPRESSION> [ROWLIMIT X]
> [COLLIMIT Y] [ASC|DESC]
> {code}
> Where:
> * <CF> is the column family name.
> * <EXPRESSION> consists of relations chained by the AND keyword.
> * <LVL> corresponds to one of the enum values in the RPC interface(s).
> What is still undone:
> * Support for indexes
> * Counts
> * Complete test coverage
> And of course, all of this is still very much open to further discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
