incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiller, Dean" <>
Subject Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
Date Mon, 04 Mar 2013 13:01:37 GMT
For us, this was an issue creating tables in 1.1.4 using thrift, then upgrading to 1.2.2. 
We did not use cli to create anything.  I will try the complete test again today and hopefully
get more detail(I didn't know I could not run the same thrift code in 1.2.2 for keyspace creation/table


From: aaron morton <<>>
Reply-To: "<>" <<>>
Date: Sunday, March 3, 2013 11:09 PM
To: "<>" <<>>
Subject: Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)

Is this an issue with tables created using CQL 3 ?


An issue with tables created in 1.1.4 using the CLI not been readable after an in place upgrade
to 1.2.2 ?

I did a quick test and it worked.


Aaron Morton
Freelance Cassandra Developer
New Zealand


On 3/03/2013, at 8:18 PM, Edward Capriolo <<>>

Your other option is to create tables 'WITH COMPACT STORAGE'. Basically if you use COMPACT
STORAGE and create tables as you did before.

>From an application standpoint, if you can't do sparse, wide rows, you break compatibility
with 90% of Cassandra applications. So that rules out almost everything; if you can't provide
the same data model, you're creating fragmentation, not pluggability.

I now call Cassandra compact storage 'c*' storage, and I call CQL3 storage 'c*++' storage.
See debates on c vs C++ to understand why :).

On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman <<>>

I think if you look back through previous mailing list items you'll find
answers to this already but to summarize:

Tables created prior to 1.2 will continue to work after upgrade. New
tables created are not exposed by the Thrift API. It is up to client
developers to upgrade the client to pull the required metadata for
serialization and deserialization of the data from the System column
family instead.

I don't know Netflix's time table for an update to Astyanax but I'm sure
they are working on it. Alternatively, you can also  use the Datastax java
driver in your QA environment for now.

If you only need to access existing column families this shouldn't be an

On 3/3/13 6:31 PM, "Hiller, Dean" <<>>

>I remember huge discussions on backwards compatibility and we have a ton
>of code using thrift(as do many people out there).  We happen to have a
>startup bean for development that populates data in cassandra for us.  We
>cleared out our QA completely(no data) and ran thisŠ.it<http://thisŠ.it> turns
out there
>seems to be no backwards compatibility as it utterly fails.
>From astyanax point of view, we simply get this (when going back to
>1.1.4, everything works fine.  I can go down the path of finding out
>where backwards compatibility breaks but does this mean essentially
>everyone has to rewrite their applications?  OR is there a list of
>breaking changes that we can't do anymore?  Has anyone tried the latest
>astyanax client with 1.2.2 version?
>An unexpected error occured caused by exception RuntimeException:
>NoAvailableHostsException: [host=None(, latency=0(0),
>attempts=0]No hosts to borrow from

Copy, by Barracuda, helps you store, protect, and share all your amazing

things. Start today:<>.

View raw message