ok, we are talking about all thrift / cli / hector / no CQL tables not been read after an upgrade. 

If you can get some repo steps that would be handy.

Aaron Morton
Freelance Cassandra Developer
New Zealand


On 4/03/2013, at 5:01 AM, "Hiller, Dean" <Dean.Hiller@nrel.gov> wrote:

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 creation)


From: aaron morton <aaron@thelastpickle.com<mailto:aaron@thelastpickle.com>>
Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Date: Sunday, March 3, 2013 11:09 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
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 <edlinuxguru@gmail.com<mailto:edlinuxguru@gmail.com>> wrote:

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 <mkjellman@barracuda.com<mailto:mkjellman@barracuda.com>> wrote:

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" <Dean.Hiller@nrel.gov<mailto:Dean.Hiller@nrel.gov>> wrote:

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: www.copy.com<http://www.copy.com/>.