[
https://issues.apache.org/jira/browse/CASSANDRA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928823#action_12928823
]
Eric Evans commented on CASSANDRA-1704:
---------------------------------------
In reply to comment #9:
> 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.)
Ultimately I think the best result is to return the proper type, but Avro isn't
going to make this easy since we're expected to create that schema up-front.
This is one of the reasons I've stated my desire to (in a future version)
create our own wire protocol, so that we could annotate the results with type
information.
In the short term, one option would be to add result encoders to the drivers
that converted the results based on the column family configuration.
> 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).
Yeah, I don't think I'm a fan of this, (and at least not for 1.0). Under what
circumstances would you even want to encode a result to a type that was
different than the one used to validate and/or sort it for storage?
> 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.
