cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Ancona (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1704) CQL reads (aka SELECT)
Date Fri, 05 Nov 2010 18:16:43 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928722#action_12928722
] 

Jim Ancona commented on CASSANDRA-1704:
---------------------------------------

Is the plan to just return Avro Columns, to annotate those with types, and/or actually convert
the names and values to a type before returning them? (The types would come either from meta-data
on the server or conversions specified in the query.) 

In the latter two cases, the language needs to have syntax to specify conversions  in both
directions (names and values to bytes and bytes to names and values in results).

If it's the former, then CQL doesn't strictly need syntax for both conversions, but clients
would still need some way to specify how to deserialize the returned bytes. They could enhance
the language to allow that (which implies they'd have to parse the enhanced language) or they
could have their own mechanism (e.g. query for metadata separately and/or make the user specify
it as part of their API).

I'd rather see language syntax support both conversions, and have the results either annotated
or converted server-side. Clients that want to do their own deserialization could of course
specify that results should be returned as bytes.


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


Mime
View raw message