Cassandra Drivers Released!
By Eric Evans
14 Oct 2011
Category:
Technical Articles
Within the Apache Cassandra Project, the status of client code has been evolving over time. The default position has been that client code is something to be maintained by third-parties. There were a number of reasons for taking this position, not least of which was a desire to allow innovation: if a standard is needed, better to let it emerge rather than anoint one.
Dude, Where's My Driver?
Database drivers however were kept within the project itself. The reasoning was that the concept of "driver" is meant to constitute the lowest level bits, things like parameter substitution, protocol abstraction, and connection pooling, the elements common to any client library. As they have progressed however, these drivers have evolved into higher-level abstractions, typically adopting a standard for database connectivity in the target platform (JDBC, DB-API 2, etc). This had the effect of putting those of us working on the Cassandra project into the business of maintaining clients, something we'd taken pains to avoid before.
Many of these drivers may have evolved past the point where it makes sense to maintain them within Cassandra, but they still fall quite short of high-level clients like Hector or Pycassa. And, unlike projects such as Hector or Pycassa, competing implementations don't make as much sense since they are based on standards that leave little room to differentiate. A compromise was needed, something between maintenance inside Cassandra, and a complete disavowal of All Things Client.
Apache Extras
The compromise that was struck was to spin the drivers off into their own projects hosted on Apache Extras. Each of these new projects will have the same code as before, and the same people working on them, but each will have it's own project page, bug tracking, and source control as well. Each project is free to choose it's own members, and to make it's own decisions.
A set of common conventions (project naming, licensing, etc) and the Apache Extras branding will help to identify drivers with a close association, and an as-of-yet-finalized list of testing and acceptance criteria will be used by the Cassandra project to "certify" qualifying drivers.
When Cassandra developers and client maintainers need to coordinate, the client-dev@cassandra.apache.org mailing list will provide the venue, and commits for each of the drivers are copied to commits@cassandra.apache.org to keep everyone in the loop.
It's been an awkward, and at times frustrating trip to get to this point, but I'm pleased with this new direction, and confident that this brings us closer to ideal.
JDBC and DBAPI2 Live
As particular examples of this brave new world, I'm pleased to announce that with the completion of CASSANDRA-3180 and CASSANDRA-3300, the Python DB-API2 and JDBC driver moves to Apache Extras are now complete. You can find the code for each at here and here respectively.
Keep your eye on these projects for updates in the weeks to come, and if you're holding out for Ruby and PHP, keep your eye here and here as well.
14th October, 2011 | Eric Evans | eric@acunu.com