Bleeding Edge
I’m writing this for my benefit. (Maybe other people will benefit from it, too.)
One task I have at work is to develop a Rails Web application for doing biological sample tracking and management. (I’ve written a little bit about it before.)
There was a changeset that showed up in unstable Rails (called “Edge Rails” in Rails-developer parlance) that was (is) quite seductive: hydration of associations in data model objects from input hashes. More on that feature here.
I decided to move the application to Edge Rails to take advantage of this functionality, as it would allow me to not expend mental effort necessary to write my own, similar functionality.
Things were good for a while, but then some unrelated-yet-compounding incidents occurred:
- The mass-assignment feature was removed from Edge Rails. This wasn’t good. Though I could always go back and patch the feature back in, it meant that my application was now locked to a specific revision of the Rails framework, with no clear upgrade path available.
- In production mode, the application uses an authorization system based around an Oracle database. We use a Rails plugin to access this authorization system. This plugin depends on a Ruby library called composite_primary_keys, which allows ActiveRecord, Ruby on Rails’ object-relational mapper, to make use of database tables having more than one primary key for a primary key set. Both the latest stable and latest development version of composite_primary_keys have subtle bugs with the revision of Edge Rails at which my application is currently stuck.
- The latest version of the authorization system Rails plugin contains some important fixes which are directly relevant to my application. However, I cannot upgrade due to the composite_primary_keys problem.
Long story short: I’m going to have to rip out the code that assumed the presence of a general mass-assignment facility and write my own. This is something I’m going to have to do concurrently with new feature work. So, basically, I just gave myself more work to do because I made a dumb decision.
The moral? Well, you’ve probably heard it before. Don’t use unstable code in production systems.
I know, I know. You know that. I thought I knew that.
But there’s a certain level of trust that you place in some codebases that are known for producing regular high-quality releases, even if they don’t tag them as official releases. The Ruby on Rails codebase is one of those codebases: I’ve used non-official releases from them before, in production systems, and have gotten away with it.
But I only just got away with it.
Lesson learnt.
NOTE: I don’t think this sort of thing is really all that unique to Rails, or even Web development, at all. I’ve worked on projects ranging from Windows kernel drivers to enterprisey Web apps, and compatibility/integration headaches were the one thing I could always count on. Really, you’d think I would have learned this lesson earlier.
But new features! They’re so alluring!
Yeah, I gotta learn to suppress that impulse better.

