[
https://issues.apache.org/jira/browse/CASSANDRA-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491876#comment-13491876
]
Nate McCall commented on CASSANDRA-4924:
----------------------------------------
bq. How do you keep a tool written for C* 1.0, that doesn't know these fields
exists, from misinterpreting it based on the fields that it does know about?
Like this is the first change on the CfDef struct? We've been managing that on
the client for the past 2.5 years with well typed exceptions (most times :)
when you do something dumb. All version of cassandra and hector 0.8 <--> 1.0
<--> 1.1 work with as much as possible. "Interop works fine - just don't do
anything with programatic keyspace/cf stuff" is a frequent reply on our mail
list for such. Users are fine with that.
> 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
