Edward, My issue isn't in doing the work, I just don't want to do a lot of work if 8 is going to be out in a month or two. That's just common sense. Especially if I can't upgrade an existing implementation without incurring undue risk.
<and I'd rather die than use Hibernate - just for the record> -----Original Message----- From: Edward Capriolo [mailto:edlinuxg...@gmail.com] Sent: Tuesday, March 29, 2011 9:58 PM To: user@cassandra.apache.org Subject: Re: Ditching Cassandra On Tue, Mar 29, 2011 at 9:56 PM, Colin <colpcl...@gmail.com> wrote: > Eric, > > Seems like the answer to everything is 8. > > 8 has been very painful. > > Are you saying that 8 will or not be compatible with 7? > > If not, would you recommend waiting until 8? We have done an awful lot of work, have an awful lot of work left, and have become very frustrated. > > Any idea on when 8 will be available? > > > On Mar 29, 2011, at 8:15 PM, Eric Evans <eev...@rackspace.com> wrote: > >> On Wed, 2011-03-30 at 02:11 +0200, Gregori Schmidt wrote: >>> - The API is horrible and it produces pointlessly verbose code in >>> addition to being utterly confusing. EVERYTHING takes a lot of >>> time to implement with Cassandra, and to be frank, it is incredibly >>> tiring. For this reason alone I no longer recommend Cassandra. If >>> you want an example, pick up the O'Reilly book on Cassandra and look >>> through the examples. Such MASSIVE amounts of code for doing nearly >>> NOTHING. This is ridiculous. Didn't this strike anyone else as >>> ridiculous? It should have! >> >> Yes, it did, which is why for 0.8 we have CQL >> (https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co). >> >>> - You need to have official client libraries and they need to be >>> programmer friendly. Yes, I know there are nice people >>> maintaining a plethora of different libraries, but you need to man >>> up and face >>> reality: the chaos that is the Cassandra client space is a horrible >>> mess. >> >> The client space as a whole *is* a mess, despite heroic efforts on >> the part of our third-party API maintainers, but forcing them in-tree >> is not going to solve anything. In fact, it would very likely make >> it worse by adding unnecessary overhead to contribution, and >> discouraging innovation. >> >> The root cause goes back to your first point, the RPC interface is >> baroque, and too tightly coupled to Cassandra's internals. The >> third-party library maintainers can only do so much to paper over >> that; The Fail shines through. >> >> The solution here is the same as for point #1 above, CQL. And, the >> idea is to include in-tree "drivers", basically, the minimum amount >> of common code that all third-party libs would need to implement >> (think connection pooling, parameter substitution, etc). We already >> have drivers for Java, Python, and Twisted, and folks are working PHP >> and Perl (that I'm aware of). >> >>> - It is buggy and the solution seems to be to just go to the next >>> release. And the next. And the next. Which would be okay if you >>> could upgrade all the time, but what to do once you hit production? >> >> 0.7 has been a rough ride, no doubt. We spent too much time pushing >> in too many features, and didn't do a good job of drawing a line in >> the sand when it came time to release. Our track record prior to 0.7 >> was Not Horrible, and trending toward Better And Better, and we've >> made some adjustment to the release process, so I'm hopeful we'll get >> back on track. >> >> Also, new for 0.8 is backward compatible messaging, which will allow >> you to smoothly perform rolling (non-disruptive) upgrades. That, >> combined with a stable query interface (CQL), will really reduce the >> barrier to upgrades. >> >>> I would recommend that everyone interested in improving Cassandra >>> take the day off, download MongoDB and read >>> https://github.com/karlseguin/the-little-mongodb-book . Then, while >>> you are downloading, unpacking, looking at what was in the JAR, >>> reading the book and pawing through the examples: _pay attention_ to >>> the neatness and the effortlessness the ease with which you can use >>> MongoDB. Then spend the rest of the day implementing something on >>> top of it to gain some hacking experience. >>> >>> No, really. Do it. This is important. You need to connect with >>> the user and you need to understand what you ought to be aspiring to. >>> >>> In any case, thanks for all the effort that went into Cassandra. I >>> will check back from time to time and perhaps in a year or so it'll >>> be time to re-evaluate Cassandra. >> >> In a year we'll have achieved Total World Domination. :) >> >>> PS: one last thing. It took us less time to rewrite the >>> DB-interface for our system to MongoDB AND port over our data than >>> it took to write the Cassandra implementation. >> -- >> Eric Evans >> eev...@rackspace.com >> > While I respect your decision... If you are tired of writing code there are solutions around coding everything there are tools like http://code.google.com/p/kundera/ This is verbose: http://java.sun.com/developer/onlineTraining/Beans/EJBTutorial/step4.html Or this: http://www.roseindia.net/hibernate/firstexample.shtml I am sure someone will soon generate tons all kinds of fancy "easy" stuff for cassandra like ECB or Cassanbernate that will be much more complex and less efficient then writing your own pojos that everyone will have wet dreams over.
