incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Fw: Fwd: CQL & Thrift
Date Fri, 30 Aug 2013 18:23:24 GMT
This is always so hard to explain but

http://www.datastax.com/dev/blog/thrift-to-cql3

Get to the part that looks like this:

update column family user_profiles
with key_validation_class = UTF8Type
and comparator = UTF8Type
and column_metadata=[]

"Since the static column values validation types have been dropped, they
are not available to your client library anymore. In particular, as can be
seen in the output above, cqlsh display some value in a non human-readable
format. And unless the client library exposes an easy way to force the
deserialization format for a value, such deserialization will have to be
done manually in client code."

This I think the above is largest reason. Due to the way 'CQL'  wants to
present 'thrift' column familes, you have to lose your 'thrift' notion of
schema, because it is not compatible with the 'cql' notion of schema. I am
wrapping 'thrift' and 'cql' in quotes because 'CQL' is an access language,
but when you define tables as non-compact storage they gain 'features' that
make them not understandable by non-cql clients.

They have two different schema systems, two different access languages,
there is some compatibility between the two, but working out which feature
sets mix and match is more effort then just picking one.


On Fri, Aug 30, 2013 at 2:05 PM, Vivek Mishra <vivek.mishra@yahoo.com>wrote:

> fyi. Just curious to know the real reason behind "not to mix thrift and
> CQL3".
>
> Any pointers?
>
> -Vivek
>
>
>
> ---------- Forwarded message ----------
> From: Vivek Mishra <mishra.vivs@gmail.com>
> Date: Fri, Aug 30, 2013 at 11:21 PM
> Subject: Re: CQL & Thrift
> To: user@cassandra.apache.org
>
>
>
> Hi,
> I understand that, but i want to understand the reason behind
> such behavior?  Is it because of maintaining different metadata objects for
> CQL3 and thrift?
>
> Any suggestion?
>
> -Vivek
>
>
>
> On Fri, Aug 30, 2013 at 11:15 PM, Jon Haddad <jon@jonhaddad.com> wrote:
>
> If you're going to work with CQL, work with CQL.  If you're going to work
> with Thrift, work with Thrift.  Don't mix.
> >
> >
> >On Aug 30, 2013, at 10:38 AM, Vivek Mishra <mishra.vivs@gmail.com> wrote:
> >
> >Hi,
> >>If i a create a table with CQL3 as
> >>
> >>
> >>create table user(user_id text PRIMARY KEY, first_name text, last_name
> text, emailid text);
> >>
> >>
> >>and create index as:
> >>create index on user(first_name);
> >>
> >>
> >>then inserted some data as:
> >>insert into user(user_id,first_name,last_name,"emailId")
> values('@mevivs','vivek','mishra','vivek.mishra@impetus.co.in');
> >>
> >>
> >>
> >>
> >>
> >>Then if update same column family using Cassandra-cli as:
> >>
> >>
> >>update column family user with key_validation_class='UTF8Type' and
> column_metadata=[{column_name:last_name, validation_class:'UTF8Type',
> index_type:KEYS},{column_name:first_name, validation_class:'UTF8Type',
> index_type:KEYS}];
> >>
> >>
> >>
> >>
> >>
> >>Now if i connect via cqlsh and explore user table, i can see column
> first_name,last_name are not part of table structure anymore. Here is the
> output:
> >>
> >>
> >>CREATE TABLE user (
> >>  key text PRIMARY KEY
> >>) WITH
> >>  bloom_filter_fp_chance=0.010000 AND
> >>  caching='KEYS_ONLY' AND
> >>  comment='' AND
> >>  dclocal_read_repair_chance=0.000000 AND
> >>  gc_grace_seconds=864000 AND
> >>  read_repair_chance=0.100000 AND
> >>  replicate_on_write='true' AND
> >>  populate_io_cache_on_flush='false' AND
> >>  compaction={'class': 'SizeTieredCompactionStrategy'} AND
> >>  compression={'sstable_compression': 'SnappyCompressor'};
> >>
> >>
> >>cqlsh:cql3usage> select * from user;
> >>
> >>
> >> user_id
> >>---------
> >> @mevivs
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>I understand that, CQL3 and thrift interoperability is an issue. But
> this looks to me a very basic scenario.
> >>
> >>
> >>
> >>
> >>
> >>
> >>Any suggestions? Or If anybody can explain a reason behind this?
> >>
> >>
> >>-Vivek
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message