On the bleeding edge

Case 1

We use JRuby with Mongrel and Derby, developing in Eclipse. We wrote many custom scripts to ease development, to start/stop servers, run rake scripts. We hack Mongrel because it couldn’t work with JRuby then. We patch ActiveRecord JDBC manually to make Derby behave correctly. Eclipse RadRails wouldn’t play well because we’re not using CRuby.

Few months after the release of our product, Aptana releases an Eclipse IDE with RadRails that completely supports JRuby, therefore run rake scripts, supports running the Rails app in Mongrel, and supports the Derby database.

Case 2 (today)

Deployment test of a new JRuby app on a new machine. During gem install we realize a new version of ActiveRecord 2.1 (from 2.0.2). Rake migration wouldn’t run after it because the SQL statement generated a “DEFAULT NULL NULL” in a CREATE TABLE statement.

Traced the code, found issue to be likely in activerecord-jdbc. Looked at JRuby Extras, and activerecord-jdbc-adapter had 0.8.1, release June 4, 2008 (today). Checked the SVN source, Nick Sieger checked in barely 6 hours ago at 5:19am to “Fix problem with AR 2.1 and Derby with ‘DEFAULT NULL NULL’ in column defs” (as per SVN commit comment).

Upgraded the gem from 0.8 to 0.8.1, but we got an “undefined method `true?’ for false:FalseClass” right at the line of Nick’s fix.

Filed my second JRuby (ActiveRecord) bug.

* We did force versions during gem install, but we didn’t expect the new version to screw up so much.

Leave a Reply