You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Vivek Mishra <mi...@gmail.com> on 2013/08/30 19:38:25 UTC

CQL & Thrift

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

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
And surprisingly if i alter table as :

alter table user add first_name text;
alter table user add last_name text;

It gives me back column with values, but still no indexes.

Thrift and CQL3 depends on same storage engine. Do they really maintain
different metadata for same column family?

-Vivek



On Fri, Aug 30, 2013 at 11:08 PM, Vivek Mishra <mi...@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
>
>
>
>
>

Re: Fw: Fwd: CQL & Thrift

Posted by Vivek Mishra <vi...@yahoo.com>.
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 <ed...@gmail.com>
To: "dev@cassandra.apache.org" <de...@cassandra.apache.org>; Vivek Mishra <vi...@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 <vi...@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 <mi...@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 <jo...@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 <mi...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>

Re: Fw: Fwd: CQL & Thrift

Posted by Edward Capriolo <ed...@gmail.com>.
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 <vi...@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 <mi...@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 <jo...@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 <mi...@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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

Fw: Fwd: CQL & Thrift

Posted by Vivek Mishra <vi...@yahoo.com>.
fyi. Just curious to know the real reason behind "not to mix thrift and CQL3".

Any pointers?

-Vivek



---------- Forwarded message ----------
From: Vivek Mishra <mi...@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 <jo...@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 <mi...@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
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
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 <jo...@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 <mi...@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
>
>
>
>
>
>

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
CQL is too limiting and negates the power of storing arbitrary data types
in dynamic columns.

I agree but partly. You can always create column family with key, column
and value and store any number of arbitrary columns as column name in
"column" and it's corresponding value with "value".  I find it much easier.

Coming back to original question, i think differentiator is the column
metadata is treated in thrift and CQL3. What i do not understand is, for
same column family if maintaining two set of metadata
objects(CqlMetadata,CFDef), why updating anyone would cause trouble for
another!

-Vivek


On Fri, Aug 30, 2013 at 11:23 PM, Peter Lin <wo...@gmail.com> wrote:

>
> my bias perspective, I find the sweet spot is thrift for insert/update and
> CQL for select queries.
>
> CQL is too limiting and negates the power of storing arbitrary data types
> in dynamic columns.
>
>
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>
>>
>>
>>
>>
>>
>

Re: CQL & Thrift

Posted by Jon Haddad <jo...@jonhaddad.com>.
Could you please give a more concrete example?  

On Aug 30, 2013, at 11:10 AM, Peter Lin <wo...@gmail.com> wrote:

> 
> in my case, I built a temporal database on top of Cassandra, so it's absolutely key.
> 
> Dynamic columns are super powerful, which relational database have no equivalent. For me, that is one of the top 3 reasons for using Cassandra.
> 
> 
> 
> On Fri, Aug 30, 2013 at 2:03 PM, Vivek Mishra <mi...@gmail.com> wrote:
> If you talk about comparator. Yes, that's a valid point and not possible with CQL3.
> 
> -Vivek
> 
> 
> On Fri, Aug 30, 2013 at 11:31 PM, Peter Lin <wo...@gmail.com> wrote:
> 
> I use dynamic columns all the time and they vary in type.
> 
> With CQL you can define a default type, but you can't insert specific types of data for column name and value. It forces you to use all bytes or all strings, which would require coverting it to other types.
> 
> thrift is much more powerful in that respect.
> 
> not everyone needs to take advantage of the full power of dynamic columns.
> 
> 
> On Fri, Aug 30, 2013 at 1:58 PM, Jon Haddad <jo...@jonhaddad.com> wrote:
> Just curious - what do you need to do that requires thrift?  We've build our entire platform using CQL3 and we haven't hit any issues.  
> 
> On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:
> 
>> 
>> my bias perspective, I find the sweet spot is thrift for insert/update and CQL for select queries.
>> 
>> CQL is too limiting and negates the power of storing arbitrary data types in dynamic columns.
>> 
>> 
>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 


Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
in my case, I built a temporal database on top of Cassandra, so it's
absolutely key.

Dynamic columns are super powerful, which relational database have no
equivalent. For me, that is one of the top 3 reasons for using Cassandra.



On Fri, Aug 30, 2013 at 2:03 PM, Vivek Mishra <mi...@gmail.com> wrote:

> If you talk about comparator. Yes, that's a valid point and not possible
> with CQL3.
>
> -Vivek
>
>
> On Fri, Aug 30, 2013 at 11:31 PM, Peter Lin <wo...@gmail.com> wrote:
>
>>
>> I use dynamic columns all the time and they vary in type.
>>
>> With CQL you can define a default type, but you can't insert specific
>> types of data for column name and value. It forces you to use all bytes or
>> all strings, which would require coverting it to other types.
>>
>> thrift is much more powerful in that respect.
>>
>> not everyone needs to take advantage of the full power of dynamic columns.
>>
>>
>> On Fri, Aug 30, 2013 at 1:58 PM, Jon Haddad <jo...@jonhaddad.com> wrote:
>>
>>> Just curious - what do you need to do that requires thrift?  We've build
>>> our entire platform using CQL3 and we haven't hit any issues.
>>>
>>> On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:
>>>
>>>
>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>> and CQL for select queries.
>>>
>>> CQL is too limiting and negates the power of storing arbitrary data
>>> types in dynamic columns.
>>>
>>>
>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
If you talk about comparator. Yes, that's a valid point and not possible
with CQL3.

-Vivek


On Fri, Aug 30, 2013 at 11:31 PM, Peter Lin <wo...@gmail.com> wrote:

>
> I use dynamic columns all the time and they vary in type.
>
> With CQL you can define a default type, but you can't insert specific
> types of data for column name and value. It forces you to use all bytes or
> all strings, which would require coverting it to other types.
>
> thrift is much more powerful in that respect.
>
> not everyone needs to take advantage of the full power of dynamic columns.
>
>
> On Fri, Aug 30, 2013 at 1:58 PM, Jon Haddad <jo...@jonhaddad.com> wrote:
>
>> Just curious - what do you need to do that requires thrift?  We've build
>> our entire platform using CQL3 and we haven't hit any issues.
>>
>> On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:
>>
>>
>> my bias perspective, I find the sweet spot is thrift for insert/update
>> and CQL for select queries.
>>
>> CQL is too limiting and negates the power of storing arbitrary data types
>> in dynamic columns.
>>
>>
>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
I use dynamic columns all the time and they vary in type.

With CQL you can define a default type, but you can't insert specific types
of data for column name and value. It forces you to use all bytes or all
strings, which would require coverting it to other types.

thrift is much more powerful in that respect.

not everyone needs to take advantage of the full power of dynamic columns.


On Fri, Aug 30, 2013 at 1:58 PM, Jon Haddad <jo...@jonhaddad.com> wrote:

> Just curious - what do you need to do that requires thrift?  We've build
> our entire platform using CQL3 and we haven't hit any issues.
>
> On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:
>
>
> my bias perspective, I find the sweet spot is thrift for insert/update and
> CQL for select queries.
>
> CQL is too limiting and negates the power of storing arbitrary data types
> in dynamic columns.
>
>
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>
>>
>>
>>
>>
>>
>
>

Re: CQL & Thrift

Posted by Les Hazlewood <lh...@apache.org>.
Yes, that's correct - and that's a scaled number.  In practice:

On the local dev machine, CQL3 inserting 10,000 columns (for 1 row) in a
BATCH took 1.5 minutes.  50,000 columns (the desired amount) in a BATCH
took 7.5 minutes.  The same Thrift functionality took _235 milliseconds_.
 That's almost 2,000 times faster (3 orders of magnitude difference)!

However, according to Aleksey Yeschenko, this performance problem has been
addressed in 2.0 beta 1 via
https://issues.apache.org/jira/browse/CASSANDRA-4693.

I'll reserve judgement until I can performance-test 2.0 beta 1 ;)

Cheers,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282

On Fri, Aug 30, 2013 at 12:50 PM, Alex Popescu <al...@datastax.com> wrote:

> On Fri, Aug 30, 2013 at 11:56 AM, Vivek Mishra <mi...@gmail.com>wrote:
>
>> @lhazlewood
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-5959
>>
>> Begin batch
>>
>>      multiple insert statements.
>>
>> apply batch
>>
>> It doesn't work for you?
>>
>> -Vivek
>>
>>
> According to the OP batching inserts is slow. The SO thread [1] mentions
> that the in their environment BATCH takes 1.5min, while the Thrift-based
> approach is around 235millis.
>
> [1]
> http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque
> --
>
> :- a)
>
>
> Alex Popescu
> Sen. Product Manager @ DataStax
> @al3xandru
>

Re: CQL & Thrift

Posted by Alex Popescu <al...@datastax.com>.
On Fri, Aug 30, 2013 at 11:56 AM, Vivek Mishra <mi...@gmail.com>wrote:

> @lhazlewood
>
> https://issues.apache.org/jira/browse/CASSANDRA-5959
>
> Begin batch
>
>      multiple insert statements.
>
> apply batch
>
> It doesn't work for you?
>
> -Vivek
>
>
According to the OP batching inserts is slow. The SO thread [1] mentions
that the in their environment BATCH takes 1.5min, while the Thrift-based
approach is around 235millis.

[1]
http://stackoverflow.com/questions/18522191/using-cassandra-and-cql3-how-do-you-insert-an-entire-wide-row-in-a-single-reque
-- 

:- a)


Alex Popescu
Sen. Product Manager @ DataStax
@al3xandru

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
@lhazlewood

https://issues.apache.org/jira/browse/CASSANDRA-5959

Begin batch

     multiple insert statements.

apply batch

It doesn't work for you?

-Vivek
On Sat, Aug 31, 2013 at 12:21 AM, Les Hazlewood <lh...@apache.org>wrote:

> On Fri, Aug 30, 2013 at 10:58 AM, Jon Haddad <jo...@jonhaddad.com> wrote:
>
>> Just curious - what do you need to do that requires thrift?  We've build
>> our entire platform using CQL3 and we haven't hit any issues.
>>
>
> Here's one thing: If you're using wide rows and you want to do anything
> other than just append individual columns to the row, then CQL3 (as it
> functions currently) is way too slow.
>
> I just created the following Jira issue 5 minutes ago because we've been
> fighting with this issue for the last 2 days. Our workaround was to swap
> out CQL3 + DataStax Java Driver in favor of Astyanax for this particular
> use case:
>
> https://issues.apache.org/jira/browse/CASSANDRA-5959
>
> Cheers,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>

Re: CQL & Thrift

Posted by Les Hazlewood <lh...@apache.org>.
On Fri, Aug 30, 2013 at 10:58 AM, Jon Haddad <jo...@jonhaddad.com> wrote:

> Just curious - what do you need to do that requires thrift?  We've build
> our entire platform using CQL3 and we haven't hit any issues.
>

Here's one thing: If you're using wide rows and you want to do anything
other than just append individual columns to the row, then CQL3 (as it
functions currently) is way too slow.

I just created the following Jira issue 5 minutes ago because we've been
fighting with this issue for the last 2 days. Our workaround was to swap
out CQL3 + DataStax Java Driver in favor of Astyanax for this particular
use case:

https://issues.apache.org/jira/browse/CASSANDRA-5959

Cheers,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
True for newly build platform(s), but what about existing apps build using
thrift? As per http://
www.datastax.com/dev/blog/thrift-to-cql3<http://www.datastax.com/dev/blog/thrift-to-cql3>
it
should be easy.

I am just curious to understand the real reason behind such behavior.

-Vivek



On Fri, Aug 30, 2013 at 11:28 PM, Jon Haddad <jo...@jonhaddad.com> wrote:

> Just curious - what do you need to do that requires thrift?  We've build
> our entire platform using CQL3 and we haven't hit any issues.
>
> On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:
>
>
> my bias perspective, I find the sweet spot is thrift for insert/update and
> CQL for select queries.
>
> CQL is too limiting and negates the power of storing arbitrary data types
> in dynamic columns.
>
>
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>
>>
>>
>>
>>
>>
>
>

Re: CQL & Thrift

Posted by Jon Haddad <jo...@jonhaddad.com>.
Just curious - what do you need to do that requires thrift?  We've build our entire platform using CQL3 and we haven't hit any issues.  

On Aug 30, 2013, at 10:53 AM, Peter Lin <wo...@gmail.com> wrote:

> 
> my bias perspective, I find the sweet spot is thrift for insert/update and CQL for select queries.
> 
> CQL is too limiting and negates the power of storing arbitrary data types in dynamic columns.
> 
> 
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>> 
>> 
>> 
>> 
> 
> 


Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
I don't consider it a fault of the database. On the contrary, I think it's
a fantastic feature of Cassandra.

Just to be clear, it is a limitation of SQL approach. If CQL were to
deviate from SQL, it could harness the full power that already exists in
Cassandra.

my bias perspective. Think of it another way.

How often does the schema change over the life of the application?
How often do you know the exact model the application needs and it doesn't
need changes in the future?




On Fri, Aug 30, 2013 at 2:43 PM, Jon Haddad <jo...@jonhaddad.com> wrote:

> It seems really strange to me that you're create a table with specific
> types then try to deviate from it.  Why not just use the "blob" type, then
> you can store whatever you want in there?
>
> The whole point of adding strong typing is to adhere to it.  I wouldn't
> consider it a fault of the database that it does what you asked it to.
>
>
> On Aug 30, 2013, at 11:33 AM, Peter Lin <wo...@gmail.com> wrote:
>
>
> In the interest of education and discussion.
>
> I didn't mean to say CQL3 doesn't support dynamic columns. The example
> from the page shows default type defined in the create statement.
>
> create column family data
> with key_validation_class=Int32Type
>  and comparator=DateType
>  and default_validation_class=FloatType;
>
>
> If I try to insert a dynamic column that uses double for column name and
> string for column value, it will throw an error. The kind of use case I'm
> talking about defines a minimum number of static columns. Most of the
> columns that are added at runtime are different name and value type. This
> is specific to my use case.
>
> Having said that, I believe it "would" be possible to provide that kind of
> feature in CQL, but the trade off is it deviates from SQL. The grammar
> would have to allow type declaration in the columns list and functions in
> the values. Something like
>
> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
> ('abc123', "some string", double(102.211))
>
> doubleType(newcol1) and string(newcol2) are dynamic columns.
>
> I know many people find thrift hard to grok and struggle with it, but I'm
> a firm believer in taking time to learn. Every developer should take time
> to read cassandra source code and the source code for the driver they're
> using.
>
>
>
> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
>>
>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>
>>
>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>
>>>
>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>> and CQL for select queries.
>>>
>>> CQL is too limiting and negates the power of storing arbitrary data
>>> types in dynamic columns.
>>>
>>>
>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>>
>
>
>

Re: CQL & Thrift

Posted by Jon Haddad <jo...@jonhaddad.com>.
It seems really strange to me that you're create a table with specific types then try to deviate from it.  Why not just use the "blob" type, then you can store whatever you want in there?

The whole point of adding strong typing is to adhere to it.  I wouldn't consider it a fault of the database that it does what you asked it to.

On Aug 30, 2013, at 11:33 AM, Peter Lin <wo...@gmail.com> wrote:

> 
> In the interest of education and discussion.
> 
> I didn't mean to say CQL3 doesn't support dynamic columns. The example from the page shows default type defined in the create statement.
> create column family data 
> with key_validation_class=Int32Type 
>  and comparator=DateType 
>  and default_validation_class=FloatType;
> 
> 
> If I try to insert a dynamic column that uses double for column name and string for column value, it will throw an error. The kind of use case I'm talking about defines a minimum number of static columns. Most of the columns that are added at runtime are different name and value type. This is specific to my use case.
> 
> Having said that, I believe it "would" be possible to provide that kind of feature in CQL, but the trade off is it deviates from SQL. The grammar would have to allow type declaration in the columns list and functions in the values. Something like
> 
> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values ('abc123', "some string", double(102.211))
> 
> doubleType(newcol1) and string(newcol2) are dynamic columns.
> 
> I know many people find thrift hard to grok and struggle with it, but I'm a firm believer in taking time to learn. Every developer should take time to read cassandra source code and the source code for the driver they're using.
> 
> 
> 
> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
> 
> 
> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
> 
> my bias perspective, I find the sweet spot is thrift for insert/update and CQL for select queries.
> 
> CQL is too limiting and negates the power of storing arbitrary data types in dynamic columns.
> 
> 
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
> 


Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
CQL3 collections is meant to store stuff that is list, set, map. Plus,
collections currently do not supporting secondary indexes.

The point is often you don't know what columns are needed at design time.
If you know what's needed, use static columns.

Using a list, set or map to store data you don't know and can't predict in
the future feels like "a hammer solution". Cassandra has this super
powerful and useful feature that developers can use via thrift.

The last time I looked DataStax's official statement is that thrift isn't
going away, so I take them at their word.



On Fri, Aug 30, 2013 at 2:51 PM, Vivek Mishra <mi...@gmail.com> wrote:

> Did you try to explore CQL3 collection support for the same? You can
> definitely save on number of rows with that.
>
> Point which i am trying to make out is, you can achieve it via CQL3 (
> Jonathan's blog :
> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
> )
>
> I agree with you that still thrift may have some valid points to prove,
> but considering latest development around new Cassandra features, i think
> CQL3 is the path to follow.
>
>
> -Vivek
>
>
> On Sat, Aug 31, 2013 at 12:15 AM, Peter Lin <wo...@gmail.com> wrote:
>
>>
>> you could dynamically create new tables at runtime and insert rows into
>> the new table, but is that better than using thrift and putting it into a
>> regular dynamic column with the exact name type and value type?
>>
>> that would mean if there's 20 dynamic columns of different types, you'd
>> have to execute 21 queries to rebuild the data. That's basically the same
>> as using EVA tables in relational databases.
>>
>>  Having used that approach in the past to build temporal databases, it
>> doesn't scale well.
>>
>>
>>
>> On Fri, Aug 30, 2013 at 2:40 PM, Vivek Mishra <mi...@gmail.com>wrote:
>>
>>> create a column family as:
>>>
>>> create table dynamicTable(key text, nameAsDouble double, valueAsBlob
>>> blob);
>>>
>>> insert into dynamicTable(key, nameAsDouble, valueAsBlob) values ( "key", double(102.211),
>>> textAsBlob('valueInBytes').
>>>
>>> Do you think, it will work in case column name are double?
>>>
>>> -Vivek
>>>
>>>
>>> On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:
>>>
>>>>
>>>> In the interest of education and discussion.
>>>>
>>>> I didn't mean to say CQL3 doesn't support dynamic columns. The example
>>>> from the page shows default type defined in the create statement.
>>>>
>>>> create column family data
>>>> with key_validation_class=Int32Type
>>>>  and comparator=DateType
>>>>  and default_validation_class=FloatType;
>>>>
>>>>
>>>> If I try to insert a dynamic column that uses double for column name
>>>> and string for column value, it will throw an error. The kind of use case
>>>> I'm talking about defines a minimum number of static columns. Most of the
>>>> columns that are added at runtime are different name and value type. This
>>>> is specific to my use case.
>>>>
>>>> Having said that, I believe it "would" be possible to provide that kind
>>>> of feature in CQL, but the trade off is it deviates from SQL. The grammar
>>>> would have to allow type declaration in the columns list and functions in
>>>> the values. Something like
>>>>
>>>> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
>>>> ('abc123', "some string", double(102.211))
>>>>
>>>> doubleType(newcol1) and string(newcol2) are dynamic columns.
>>>>
>>>> I know many people find thrift hard to grok and struggle with it, but
>>>> I'm a firm believer in taking time to learn. Every developer should take
>>>> time to read cassandra source code and the source code for the driver
>>>> they're using.
>>>>
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com>wrote:
>>>>
>>>>>
>>>>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> my bias perspective, I find the sweet spot is thrift for
>>>>>> insert/update and CQL for select queries.
>>>>>>
>>>>>> CQL is too limiting and negates the power of storing arbitrary data
>>>>>> types in dynamic columns.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jonathan Ellis
>>>>> Project Chair, Apache Cassandra
>>>>> co-founder, http://www.datastax.com
>>>>> @spyced
>>>>>
>>>>
>>>>
>>>
>>
>

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
Did you try to explore CQL3 collection support for the same? You can
definitely save on number of rows with that.

Point which i am trying to make out is, you can achieve it via CQL3 (
Jonathan's blog :
http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows)

I agree with you that still thrift may have some valid points to prove, but
considering latest development around new Cassandra features, i think CQL3
is the path to follow.


-Vivek


On Sat, Aug 31, 2013 at 12:15 AM, Peter Lin <wo...@gmail.com> wrote:

>
> you could dynamically create new tables at runtime and insert rows into
> the new table, but is that better than using thrift and putting it into a
> regular dynamic column with the exact name type and value type?
>
> that would mean if there's 20 dynamic columns of different types, you'd
> have to execute 21 queries to rebuild the data. That's basically the same
> as using EVA tables in relational databases.
>
> Having used that approach in the past to build temporal databases, it
> doesn't scale well.
>
>
>
> On Fri, Aug 30, 2013 at 2:40 PM, Vivek Mishra <mi...@gmail.com>wrote:
>
>> create a column family as:
>>
>> create table dynamicTable(key text, nameAsDouble double, valueAsBlob
>> blob);
>>
>> insert into dynamicTable(key, nameAsDouble, valueAsBlob) values ( "key", double(102.211),
>> textAsBlob('valueInBytes').
>>
>> Do you think, it will work in case column name are double?
>>
>> -Vivek
>>
>>
>> On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:
>>
>>>
>>> In the interest of education and discussion.
>>>
>>> I didn't mean to say CQL3 doesn't support dynamic columns. The example
>>> from the page shows default type defined in the create statement.
>>>
>>> create column family data
>>> with key_validation_class=Int32Type
>>>  and comparator=DateType
>>>  and default_validation_class=FloatType;
>>>
>>>
>>> If I try to insert a dynamic column that uses double for column name and
>>> string for column value, it will throw an error. The kind of use case I'm
>>> talking about defines a minimum number of static columns. Most of the
>>> columns that are added at runtime are different name and value type. This
>>> is specific to my use case.
>>>
>>> Having said that, I believe it "would" be possible to provide that kind
>>> of feature in CQL, but the trade off is it deviates from SQL. The grammar
>>> would have to allow type declaration in the columns list and functions in
>>> the values. Something like
>>>
>>> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
>>> ('abc123', "some string", double(102.211))
>>>
>>> doubleType(newcol1) and string(newcol2) are dynamic columns.
>>>
>>> I know many people find thrift hard to grok and struggle with it, but
>>> I'm a firm believer in taking time to learn. Every developer should take
>>> time to read cassandra source code and the source code for the driver
>>> they're using.
>>>
>>>
>>>
>>> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com>wrote:
>>>
>>>>
>>>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>>>
>>>>>
>>>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>>>> and CQL for select queries.
>>>>>
>>>>> CQL is too limiting and negates the power of storing arbitrary data
>>>>> types in dynamic columns.
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Ellis
>>>> Project Chair, Apache Cassandra
>>>> co-founder, http://www.datastax.com
>>>> @spyced
>>>>
>>>
>>>
>>
>

Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
This has nothing to do with compact storage.

Cassandra supports arbitrary dynamic columns of different name/value type
today. If people are happy with SQL metaphor, then CQL is fine.

Then again, if SQL metaphor was good for temporal databases, there wouldn't
be so many failed temporal databases built on RDB. I've built over 4
bi-temporal databases on RDB over the last 12 years, so it's not something
that was done lightly.

it was from years of pain. I won't bore others about the challenges of
building temporal databases.




On Fri, Aug 30, 2013 at 2:51 PM, Jon Haddad <jo...@jonhaddad.com> wrote:

> It sounds like you want this:
>
> create table data ( pk int, colname blob, value blob, primary key (pk,
> colname));
>
> that gives you arbitrary columns (cleverly labeled colname) in a single
> row, where the value is "value".
>
> If you don't want the overhead of storing "colname" in every row, try with
> compact storage.
>
> Does this solve the problem, or am I missing something?
>
> On Aug 30, 2013, at 11:45 AM, Peter Lin <wo...@gmail.com> wrote:
>
>
> you could dynamically create new tables at runtime and insert rows into
> the new table, but is that better than using thrift and putting it into a
> regular dynamic column with the exact name type and value type?
>
> that would mean if there's 20 dynamic columns of different types, you'd
> have to execute 21 queries to rebuild the data. That's basically the same
> as using EVA tables in relational databases.
>
> Having used that approach in the past to build temporal databases, it
> doesn't scale well.
>
>
>
> On Fri, Aug 30, 2013 at 2:40 PM, Vivek Mishra <mi...@gmail.com>wrote:
>
>> create a column family as:
>>
>> create table dynamicTable(key text, nameAsDouble double, valueAsBlob
>> blob);
>>
>> insert into dynamicTable(key, nameAsDouble, valueAsBlob) values ( "key", double(102.211),
>> textAsBlob('valueInBytes').
>>
>> Do you think, it will work in case column name are double?
>>
>> -Vivek
>>
>>
>> On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:
>>
>>>
>>> In the interest of education and discussion.
>>>
>>> I didn't mean to say CQL3 doesn't support dynamic columns. The example
>>> from the page shows default type defined in the create statement.
>>>
>>> create column family data
>>> with key_validation_class=Int32Type
>>>  and comparator=DateType
>>>  and default_validation_class=FloatType;
>>>
>>>
>>> If I try to insert a dynamic column that uses double for column name and
>>> string for column value, it will throw an error. The kind of use case I'm
>>> talking about defines a minimum number of static columns. Most of the
>>> columns that are added at runtime are different name and value type. This
>>> is specific to my use case.
>>>
>>> Having said that, I believe it "would" be possible to provide that kind
>>> of feature in CQL, but the trade off is it deviates from SQL. The grammar
>>> would have to allow type declaration in the columns list and functions in
>>> the values. Something like
>>>
>>> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
>>> ('abc123', "some string", double(102.211))
>>>
>>> doubleType(newcol1) and string(newcol2) are dynamic columns.
>>>
>>> I know many people find thrift hard to grok and struggle with it, but
>>> I'm a firm believer in taking time to learn. Every developer should take
>>> time to read cassandra source code and the source code for the driver
>>> they're using.
>>>
>>>
>>>
>>> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com>wrote:
>>>
>>>>
>>>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>>>
>>>>>
>>>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>>>> and CQL for select queries.
>>>>>
>>>>> CQL is too limiting and negates the power of storing arbitrary data
>>>>> types in dynamic columns.
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Ellis
>>>> Project Chair, Apache Cassandra
>>>> co-founder, http://www.datastax.com
>>>> @spyced
>>>>
>>>
>>>
>>
>
>

Re: CQL & Thrift

Posted by Jon Haddad <jo...@jonhaddad.com>.
It sounds like you want this:

create table data ( pk int, colname blob, value blob, primary key (pk, colname));

that gives you arbitrary columns (cleverly labeled colname) in a single row, where the value is "value". 

If you don't want the overhead of storing "colname" in every row, try with compact storage.

Does this solve the problem, or am I missing something?

On Aug 30, 2013, at 11:45 AM, Peter Lin <wo...@gmail.com> wrote:

> 
> you could dynamically create new tables at runtime and insert rows into the new table, but is that better than using thrift and putting it into a regular dynamic column with the exact name type and value type?
> 
> that would mean if there's 20 dynamic columns of different types, you'd have to execute 21 queries to rebuild the data. That's basically the same as using EVA tables in relational databases.
> 
> Having used that approach in the past to build temporal databases, it doesn't scale well.
> 
> 
> 
> On Fri, Aug 30, 2013 at 2:40 PM, Vivek Mishra <mi...@gmail.com> wrote:
> create a column family as:
> 
> create table dynamicTable(key text, nameAsDouble double, valueAsBlob blob);
> 
> insert into dynamicTable(key, nameAsDouble, valueAsBlob) values ( "key", double(102.211), textAsBlob('valueInBytes').
> 
> Do you think, it will work in case column name are double?
> 
> -Vivek
> 
> 
> On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:
> 
> In the interest of education and discussion.
> 
> I didn't mean to say CQL3 doesn't support dynamic columns. The example from the page shows default type defined in the create statement.
> create column family data 
> with key_validation_class=Int32Type 
>  and comparator=DateType 
>  and default_validation_class=FloatType;
> 
> 
> If I try to insert a dynamic column that uses double for column name and string for column value, it will throw an error. The kind of use case I'm talking about defines a minimum number of static columns. Most of the columns that are added at runtime are different name and value type. This is specific to my use case.
> 
> Having said that, I believe it "would" be possible to provide that kind of feature in CQL, but the trade off is it deviates from SQL. The grammar would have to allow type declaration in the columns list and functions in the values. Something like
> 
> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values ('abc123', "some string", double(102.211))
> 
> doubleType(newcol1) and string(newcol2) are dynamic columns.
> 
> I know many people find thrift hard to grok and struggle with it, but I'm a firm believer in taking time to learn. Every developer should take time to read cassandra source code and the source code for the driver they're using.
> 
> 
> 
> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
> 
> 
> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
> 
> my bias perspective, I find the sweet spot is thrift for insert/update and CQL for select queries.
> 
> CQL is too limiting and negates the power of storing arbitrary data types in dynamic columns.
> 
> 
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
> 
> 
> 


Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
you could dynamically create new tables at runtime and insert rows into the
new table, but is that better than using thrift and putting it into a
regular dynamic column with the exact name type and value type?

that would mean if there's 20 dynamic columns of different types, you'd
have to execute 21 queries to rebuild the data. That's basically the same
as using EVA tables in relational databases.

Having used that approach in the past to build temporal databases, it
doesn't scale well.



On Fri, Aug 30, 2013 at 2:40 PM, Vivek Mishra <mi...@gmail.com> wrote:

> create a column family as:
>
> create table dynamicTable(key text, nameAsDouble double, valueAsBlob blob);
>
> insert into dynamicTable(key, nameAsDouble, valueAsBlob) values ( "key", double(102.211),
> textAsBlob('valueInBytes').
>
> Do you think, it will work in case column name are double?
>
> -Vivek
>
>
> On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:
>
>>
>> In the interest of education and discussion.
>>
>> I didn't mean to say CQL3 doesn't support dynamic columns. The example
>> from the page shows default type defined in the create statement.
>>
>> create column family data
>> with key_validation_class=Int32Type
>>  and comparator=DateType
>>  and default_validation_class=FloatType;
>>
>>
>> If I try to insert a dynamic column that uses double for column name and
>> string for column value, it will throw an error. The kind of use case I'm
>> talking about defines a minimum number of static columns. Most of the
>> columns that are added at runtime are different name and value type. This
>> is specific to my use case.
>>
>> Having said that, I believe it "would" be possible to provide that kind
>> of feature in CQL, but the trade off is it deviates from SQL. The grammar
>> would have to allow type declaration in the columns list and functions in
>> the values. Something like
>>
>> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
>> ('abc123', "some string", double(102.211))
>>
>> doubleType(newcol1) and string(newcol2) are dynamic columns.
>>
>> I know many people find thrift hard to grok and struggle with it, but I'm
>> a firm believer in taking time to learn. Every developer should take time
>> to read cassandra source code and the source code for the driver they're
>> using.
>>
>>
>>
>> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com>wrote:
>>
>>>
>>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>>
>>>
>>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>>
>>>>
>>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>>> and CQL for select queries.
>>>>
>>>> CQL is too limiting and negates the power of storing arbitrary data
>>>> types in dynamic columns.
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Jonathan Ellis
>>> Project Chair, Apache Cassandra
>>> co-founder, http://www.datastax.com
>>> @spyced
>>>
>>
>>
>

Re: CQL & Thrift

Posted by Vivek Mishra <mi...@gmail.com>.
create a column family as:

create table dynamicTable(key text, nameAsDouble double, valueAsBlob blob);

insert into dynamicTable(key, nameAsDouble, valueAsBlob) values (
"key", double(102.211),
textAsBlob('valueInBytes').

Do you think, it will work in case column name are double?

-Vivek


On Sat, Aug 31, 2013 at 12:03 AM, Peter Lin <wo...@gmail.com> wrote:

>
> In the interest of education and discussion.
>
> I didn't mean to say CQL3 doesn't support dynamic columns. The example
> from the page shows default type defined in the create statement.
>
> create column family data
> with key_validation_class=Int32Type
>  and comparator=DateType
>  and default_validation_class=FloatType;
>
>
> If I try to insert a dynamic column that uses double for column name and
> string for column value, it will throw an error. The kind of use case I'm
> talking about defines a minimum number of static columns. Most of the
> columns that are added at runtime are different name and value type. This
> is specific to my use case.
>
> Having said that, I believe it "would" be possible to provide that kind of
> feature in CQL, but the trade off is it deviates from SQL. The grammar
> would have to allow type declaration in the columns list and functions in
> the values. Something like
>
> insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
> ('abc123', "some string", double(102.211))
>
> doubleType(newcol1) and string(newcol2) are dynamic columns.
>
> I know many people find thrift hard to grok and struggle with it, but I'm
> a firm believer in taking time to learn. Every developer should take time
> to read cassandra source code and the source code for the driver they're
> using.
>
>
>
> On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
>>
>> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>>
>>
>> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>>
>>>
>>> my bias perspective, I find the sweet spot is thrift for insert/update
>>> and CQL for select queries.
>>>
>>> CQL is too limiting and negates the power of storing arbitrary data
>>> types in dynamic columns.
>>>
>>>
>>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>>
>
>

Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
In the interest of education and discussion.

I didn't mean to say CQL3 doesn't support dynamic columns. The example from
the page shows default type defined in the create statement.

create column family data
with key_validation_class=Int32Type
 and comparator=DateType
 and default_validation_class=FloatType;


If I try to insert a dynamic column that uses double for column name and
string for column value, it will throw an error. The kind of use case I'm
talking about defines a minimum number of static columns. Most of the
columns that are added at runtime are different name and value type. This
is specific to my use case.

Having said that, I believe it "would" be possible to provide that kind of
feature in CQL, but the trade off is it deviates from SQL. The grammar
would have to allow type declaration in the columns list and functions in
the values. Something like

insert into mytable (KEY, doubleType(newcol1), string(newcol2)) values
('abc123', "some string", double(102.211))

doubleType(newcol1) and string(newcol2) are dynamic columns.

I know many people find thrift hard to grok and struggle with it, but I'm a
firm believer in taking time to learn. Every developer should take time to
read cassandra source code and the source code for the driver they're using.



On Fri, Aug 30, 2013 at 2:18 PM, Jonathan Ellis <jb...@gmail.com> wrote:

> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>
>
> On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:
>
>>
>> my bias perspective, I find the sweet spot is thrift for insert/update
>> and CQL for select queries.
>>
>> CQL is too limiting and negates the power of storing arbitrary data types
>> in dynamic columns.
>>
>>
>> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: CQL & Thrift

Posted by Jonathan Ellis <jb...@gmail.com>.
http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows


On Fri, Aug 30, 2013 at 12:53 PM, Peter Lin <wo...@gmail.com> wrote:

>
> my bias perspective, I find the sweet spot is thrift for insert/update and
> CQL for select queries.
>
> CQL is too limiting and negates the power of storing arbitrary data types
> in dynamic columns.
>
>
> On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>>
>>
>>
>>
>>
>>
>


-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: CQL & Thrift

Posted by Peter Lin <wo...@gmail.com>.
my bias perspective, I find the sweet spot is thrift for insert/update and
CQL for select queries.

CQL is too limiting and negates the power of storing arbitrary data types
in dynamic columns.


On Fri, Aug 30, 2013 at 1:45 PM, Jon Haddad <jo...@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 <mi...@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
>
>
>
>
>
>

Re: CQL & Thrift

Posted by Jon Haddad <jo...@jonhaddad.com>.
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 <mi...@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
> 
> 
> 
>