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 >
