True. but in my example i did not drop any column:
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}];
And surprisingly:
alter table user add first_name text;
alter table user add last_name text;
It gives me back column with values(on cqlsh), but still no indexes.
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.
<Vivek> If two different schema systems and two different languages. But why
can't they differently rather than a random behavior. I haven't looked into the
code, so not sure if my question is valid or not </Vivek>
Thanks for your reply.
-Vivek
________________________________
From: Edward Capriolo <edlinuxg...@gmail.com>
To: "dev@cassandra.apache.org" <dev@cassandra.apache.org>; Vivek Mishra
<vivek.mis...@yahoo.com>
Sent: Friday, August 30, 2013 11:53 PM
Subject: Re: Fw: Fwd: CQL & Thrift
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.mis...@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.v...@gmail.com>
>Date: Fri, Aug 30, 2013 at 11:21 PM
>Subject: Re: CQL & Thrift
>To: u...@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 <j...@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.v...@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.mis...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
