cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1704) CQL reads (aka SELECT)
Date Thu, 04 Nov 2010 19:18:43 GMT


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.

... WHERE KEY > "aaa" AND KEY < "ddd" AND "temperature" > 80 ...

> CQL reads (aka SELECT)
> ----------------------
>                 Key: CASSANDRA-1704
>                 URL:
>             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}
> {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.

View raw message