On Rails and DB2

James Governor wrote an interesting post entitled “On douchebags, DB2 and Rails: DHH not pragmatic enough?”. It’s partially in response to Jeff Atwood’s article “Douchebaggery” which, in turn is a reply to an old post by David Heinemeier Hansson. So please excuse me if I limit the entertainment value of this post by not calling anyone names. 🙂

Amongst a few sensible comments, James also argues that David may not be nearly opinionated and pragmatic enough after all:

What’s bothering me though is that perhaps Hansson isn’t opinionated enough. You see Rails targets MySQL. MySQL is the Rails database. Forget all the configuration crap and just use MySQL. There is no need to consider other database platforms. LAMP may or may not be a literal but MySQL is utterly embedded in the Rails way. In Rails database is not a design decision, its a given.

As most of you will already know, Rails was extracted from a real web application called Basecamp. This approach is thought to be the first sign (scientists believe there are 37 of them :-P) that we are dealing with a pragmatic framework. Its features and design choices weren’t defined a priori by David, but they were implemented to satisfy particular needs (and opinions) which Hansson and his team had, while developing database driven web applications.

When analyzed under a proverbial microscope, one sees that Rails didn’t actually invent anything new. Neither the MVC paradigm nor the Active record pattern were especially innovative. They’d been well known for years in the Computer Science world and even adopted (to a certain extent) within the enterprise realm. Yet, Rails was a revolutionary piece of software. What Rails did was to tie all the loose ends together into a neat, tidy package. On top of that achievement, it clearly favored simplicity, pragmatism and developer productivity over anything else. Forget about repetition and countless XML configuration files, it was opinionated software that made web development, or at least most of it, rather trivial. Less choices for the developer (the Paradox of Choice comes to mind) turned out to be a significant gain in terms of “ease of use”, which in turn bolstered Rails’ adoption.

Rails wasn’t supposed to be the answer to all web development needs everywhere – just to most of them. This means that the making of such a DSL involved a lot of assumptions. In turn, there are people who don’t use Rails due to these assumptions, and projects where adopting Rails wouldn’t probably be the smartest choice either. But Rails worked for David and 37Signals, and in doing so, it also happens to work very well for thousands of other developers around the world with similar development needs, who’re facing analogous challenges. David did his best to create a usable and enjoyable web framework, and succeeded spectacularly in responding to the needs of most web developers.

For this, Rails constantly gets accused of being far too opinionated. How many times have we seen comments about the lack of prepared statement support, that there’s no connection pool, no thread safety, no unicode, about deployment issues and so on. James’ comments are interesting because they’re entirely unusual. He’s arguing that Rails is not opinionated enough, and that in itself, is an opinion worth replying to (and not simply because he explicitly called upon my views on the subject at hand within his post):

Why in the Getting Started section of the book, do the authors even mention DB2 as a potential target database, even if its just an aside (Rails does allow exceptions it just doesn’t like them)? I mean if a DB2 bigot came to ask Hansson for a job at 37Signals he would be shit out luck wouldn’t he? You can imagine the laughs- “this guy wants to back end Rails apps with DB2 – what a ***tard.”

I know Anthony would disagree with me, and arguably Rails abstracts the database decision, so Rails is not tightly coupled to MySQL. But that’s not the point – we’re not talking about JDBC here.

I’m pretty sure that David doesn’t care about shared hosting, prepared statements, support for stored procedures, JRuby, DB2 or the “enterprise world”. It’s not his way of creating and going about web development, plus he really doesn’t have any need of these for his own purposes. Therefore don’t expect support for these points from him. However, that said, David is also being fairly reasonable with those who think differently than he does.

David’s message is: if you need these type of features, then please by all means, go ahead and implement them yourself. Rails’ core team has enabled the development community to extend Rails to fit a different kind of bill. While the policy in terms of accepting patches may be strict and not particularly welcoming of every single contribution, the plugin architecture coupled with Ruby’s flexibility and extensibility, allows the injection of substantial features which in turn significantly affect Rails. There are limits of course, and some people even preferred to create a similar framework from scratch, because they found it easier and neater to do so than to completely restructure and refactor Rails’ core.

David clearly favors opinionated conceptual integrity and the act of defining a set of sensible conventions over abstraction/modularity/extensibility, which would be regarded highly by those who require enterprise features or view web development in a markedly different way. He did not intentionally set out to block these things either though, and that’s worth remembering. He proposed his take on things, but he certainly did not impose it on anyone else. Doing so simply would not make sense (and might have required more work on his part in some cases).

Take ActiveRecord for example: it’s not a perfect abstraction, given that its Ruby implementation makes several MySQL centric assumptions in regards to SQL generation, which makes development of alternative adapters for other databases less than trivial (particularly for so called enterprise databases). But it’s still essentially a database agnostic pattern that would be almost harder not to implement as such. David’s implementation poses a few challenges here and there, but we’re still very much within the realm of possibility.

David might only use Rails with MySQL, and he may only slightly care about the subset of features which are common to all databases (including SQLite, the current default database) and nothing more, but at the same time he clearly realizes that we are not all Davids. He’s not willing to warp his creation in order to make everyone happy. That’s not David’s style. However, if other databases or options are available to Rails developers, why not mention them as a testament of the interest surrounding Rails?

The fact that DB2 is a viable (free of charge) option for Rails developers doesn’t affect the Rails core team in a perceivable way, and it still offers the possibility of using Rails to a whole new segment of programmers. Which bring us to the next point:

Anthony says “an increasing number of Rails developers adopting DB2 as their database of choice”. I would like to know more about this “increasing number” from Anthony […]

While perhaps not the most vocal bunch in the blogosphere, there are many developers and companies interested in DB2 on Rails. In my experience, I’d say that there are three main likely/common scenarios (of DB2 on Rails users):

1. Companies who have already widely adopted DB2 in their infrastructure and are now considering Rails for some of their projects. The developers involved are usually very excited about DB2 on Rails, because it means that they have a rare chance to use Ruby/Rails rather than Java/J2EE or similar technologies, with a data server that they already have a good understanding of. While some web developers choose the framework first and consider the database at a latter stage, most companies don’t work that way.
2. Developers who have DB2 skills and are looking for a good framework for developing web applications. They have no reason to use any other database but DB2.
3. Companies or developers who understand the technological advantage offered by DB2’s features (e.g. utmost speed, pureXML, compression, replication, high availability, affordable 24/7 support, etc…) and therefore choose it for their Rails based projects.

Rails doesn’t exploit advanced database features, and as a result, it doesn’t provide any further compelling reasons to adopt other databases aside from MySQL. It takes a discerning developer to realize that DB2 has much more to offer and that there are concrete benefits to adopting it – even when developing with Rails.

It’s also true that working with an independent adapter in Rails will generally be less “comfy” than using SQLite/MySQL/PostgreSQL. For example, certain tasks are not implemented for DB2 by the Rails team, and as such won’t be available. But it’s a small price to pay. In order to change this, I decided to start a project in my spare time (not an IBM project), called DB2 Extended. From the RubyForge description: “db2_extended is a Rails plugin that extends support and enhances the user experience for developers who adopt DB2 as their backend for Rails applications”. This project is currently empty, but I hope to perform the first svn commits over the weekend. I’ll start with simple things that close the gap (like making rake db:create work for DB2) and incrementally, I’d love to throw in DB2 specific functionalities and enhancements as well. Being a personal, open source project, I will more than happily accept patches and contributes from the DB2 on Rails community. Hopefully in a short period, we’ll have a plugin that makes web development with Rails and DB2 even more fun and productive.

As usual, these opinions are only mine and don’t necessarily represent my employer’s (IBM) positions, strategies or opinions.