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)
Thanks, Dean From: aaron morton <aa...@thelastpickle.com<mailto:aa...@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) Dean, Is this an issue with tables created using CQL 3 ? OR… 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. Cheers ----------------- Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 3/03/2013, at 8:18 PM, Edward Capriolo <edlinuxg...@gmail.com<mailto:edlinuxg...@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. https://issues.apache.org/jira/browse/CASSANDRA-2995 >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 <mkjell...@barracuda.com<mailto:mkjell...@barracuda.com>> wrote: Dean, 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 issue On 3/3/13 6:31 PM, "Hiller, Dean" <dean.hil...@nrel.gov<mailto:dean.hil...@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: >com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException: >NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0), >attempts=0]No hosts to borrow from > >Thanks, >Dean Copy, by Barracuda, helps you store, protect, and share all your amazing things. Start today: www.copy.com<http://www.copy.com/>.
