[
https://issues.apache.org/jira/browse/CASSANDRA-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491868#comment-13491868
]
amorton commented on CASSANDRA-4924:
------------------------------------
bq. More accurately, the table definitions are hidden, because you really
shouldn't be trying to manually perform CQL3-style encoding. But if you really
insist, batch_mutate, get_range_slice, and friends will still work as
advertised, and even validate the bytes you give them.
Are you saying this is a restriction in the cli only ?
bq. This seems like a reasonable compromise to me: tools designed for Thrift
will not try to scribble over cql3 tables inadvertently because they aren't
aware of the difference, but if you know your schema and want to do limited
manual encoding that is available to you.
Statements like "This CQL definition will store data in exactly the same way
than the thrift definition above"
(http://www.datastax.com/dev/blog/thrift-to-cql3) Created the impression two
API's were using the storage engine in an equal but different way.
Hiding table definitions from one API because it does things the other will not
understand goes against those statements and that impression.
I'm trying to understand *what* CQL 3 is, how to explain it, and how to help
people migrate to it. It looks like CQL 3 is table orientated, schema driven,
API that is incompatible with the previous Thrift/RPC way of using Cassandra.
That's a big change to come in with an API upgrade.
IMHO making the CQL 3 data read and/or write visible via thrift would make it
easier at a human level. If there is real danger of thrift API clients
essentially corrupting CQL 3 data could a config setting be added to allow read
and/or write ?
> Make CQL 3 data accessible via thrift.
> --------------------------------------
>
> Key: CASSANDRA-4924
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4924
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.2.0
> Reporter: amorton
>
> Following the changes from CASSANDRA-4377 data created using CQL 3 is not
> visible via the thrift interface.
> This goes against the spirit of many comments by the project that "the thrift
> API is not going away". These statements and ones such as "Internally, both
> CQL3 and thrift use the same storage engine, so all future improvements to
> this engine will impact both of them equally."
> (http://www.datastax.com/dev/blog/thrift-to-cql3) and the CQL3 and thrift
> examples given here
> http://www.datastax.com/dev/blog/cql3-for-cassandra-experts gave the
> impression CQL 3 was a layer on top of the core storage engine. It now
> appears to be an incompatible format change.
> It makes it impossible to explain to existing using users how CQL 3 stores
> it's data.
> It also creates an all or nothing approach to trying CQL 3.
> My request is to make all data written by CQL 3 readable via the thrift API.
> An example of using the current 1.2 trunk is below:
> {noformat}
> cqlsh:cass_college> CREATE TABLE UserTweets
> ... (
> ... tweet_id bigint,
> ... user_name text,
> ... body text,
> ... timestamp timestamp,
> ... PRIMARY KEY (user_name, tweet_id)
> ... );
> cqlsh:cass_college> INSERT INTO
> ... UserTweets
> ... (tweet_id, body, user_name, timestamp)
> ... VALUES
> ... (1, 'The Tweet', 'fred', 1352150816917);
> cqlsh:cass_college>
> cqlsh:cass_college>
> cqlsh:cass_college> select * from UserTweets;
> user_name | tweet_id | body | timestamp
> -----------+----------+-----------+--------------------------
> fred | 1 | The Tweet | 2012-11-06 10:26:56+1300
> {noformat}
> and in the CLI
> {noformat}
> [default@cass_college] show schema;
> create keyspace cass_college
> with placement_strategy = 'SimpleStrategy'
> and strategy_options = {replication_factor : 3}
> and durable_writes = true;
> use cass_college;
> [default@cass_college] list UserTweets;
> UserTweets not found in current keyspace.
> [default@cass_college]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
