Fresh 0.9.2 activerecord-jdbc-adapter Release

Posted by Nick Sieger Mon, 12 Oct 2009 18:30:45 GMT

As announced last week on the jruby-user list, 0.9.2, the latest activerecord-jdbc-adapter release, has been pushed out. Please install the gem in the usual fashion and try it out on your applications.

One of the most contentious bugs broke db:create and db:drop, ruining the quick-start workflow that Rails is known for. To fix this, a creative solution was needed that ended up bringing some nice benefits.

The problem stemmed from the fact that some database setup tasks in Rails 2.3 no longer load the environment; instead they just load the configuration data and work with that. This means that there is no easy way to hook into Rails and override those tasks, which is what activerecord-jdbc needs to do.

The solution I ended up with was to create a jdbc Rails generator that inserts a couple files into your rails application that inject the JDBC logic into ActiveRecord and the database rake tasks. To wit:

$ jruby script/generate jdbc
      exists  config/initializers
      create  config/initializers/jdbc.rb
      exists  lib/tasks
      create  lib/tasks/jdbc.rake

The upside of this new technique is that now that we have a way to ensure the JDBC adapter is properly injected into Rails, and you no longer need to use adapter names like jdbcmysql, jdbcsqlite3 and the like. The net result is that database.yml no longer needs to be modified for the default Rails databases (mysql, sqlite3, postgresql). So while we introduced one additional step in the process to bootstrap a Rails application under JRuby, the removal the step where database.yml needs to be modified results in a more predictable workflow.

The new JRuby-specific Rails workflow looks like the following, assuming you’ve installed the activerecord-jdbc-adapter gem into JRuby, along with the appropriate database driver gem (e.g, jdbc-mysql). (Of course, the gems only need to be installed once per JRuby installation.)

  1. Create your Rails application as usual.
  2. Run the jdbc generator as shown above.
  3. Profit!

Additionally, if you maintain a Rails application template that you use to start a new application, you can simply add generate(:jdbc) to that template’s script.

What’s more, the presence of the JDBC files in your application are guarded and only inject JDBC support when running under JRuby, so you can safely keep them around when running Rails under multiple Ruby implementations.

For more details of what’s in the release please consult the mini-changelog on Rubyforge and the list of fixed issues in JIRA.

Tags , ,  | 9 comments

Comments

Leave a response

  1. Avatar bryanl said about 22 hours later:

    sweet. this is a good change.

  2. Avatar acid said 1 day later:

    Sweet, thanx! :D

  3. Avatar jonbaer said 2 days later:

    Awesome fix, +1 for this, much needed for switching between MRI (dev) and JRuby (deploy)

  4. Avatar Vladimir Sizikov said 2 days later:

    Cool, now I have a link to point to every time I’m asked why db:create didn’t create the tables anymore... :)

  5. Avatar vivek.pandey@gmail.com said 3 days later:

    This is great! No more editing database.yml required. Going to help great deal in keeping the application portable between MRI. Would you follow up with releasing activerecord-jdbcmysql-adapter or activerecord-jdbcsqlite3-adapter with 0.9.2 dependency?

  6. Avatar Nick Sieger said 3 days later:

    Vivek: jdbcmysql and sqlite3 adapters are released too. But know that you don’t need them anymore; you can install just the base jdbc adapter + jdbc-mysql or jdbc-sqlite3 and that will work too.

  7. Avatar Sigi said 6 days later:

    This is a good patch, but something seems to be missing still. Here’s what I’m facing:

    I want to actually have both my native DB gem (‘postgres’ in my case) AND the Java stuff installed in the MRI gem tree.

    Although I won’t be able to use the JDBC adapter from MRI (and the patch will ensure it’s not loaded anyway), this gives me the possibility to run ‘warble’ from MRI. In other words, I want to package the Java app without having to use ‘jruby’ (or somehow juggling GEM_HOMEs).

    Now here’s the actual problem: if I have both ‘pg’ as well as ‘activerecord-jdbc-adapter’ installed (in my MRI GEM_HOME), Rails seems to load the wrong adapter. When running the app in MRI, on first DB access I get “uninitialized constant ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::PGconn”.

    Uninstalling ‘activerecord-jdbc-adapter’ restores a working condition. So it seems I cannot install it along with ‘pg’.

    This happens regardless of having the jdbc generator ran or not.

    Any advice? I’d really like to be able to WAR package AND develop with MRI, and keeping all the necessary gems installed in parallel.

  8. Avatar Sigi said 6 days later:

    Sorry for the back-to-back posting, but I’d also like to mention that even without my somewhat exotic requirement it can be very irritating to suddenly have your app not working anymore under MRI, only because you installed a Java only adapter into the wrong GEM_HOME by accident ;-).

    So if there’s an easy way to avoid this problem it should be considered.

  9. Avatar Nick Sieger said 6 days later:

    Sigi: Your case is a bit unusual, and one that I hadn’t anticipated in this latest release.

    The problem is that the only way I could work around Rails’ requirement to load ‘pg’ when the PostgreSQL adapter is loaded is to include an empty, placeholder pg.rb in activerecord-jdbc-adapter. If you simply remove that file (lib/pg.rb) in the installed ar-jdbc gem, you should be ok.

    Sadly, I’m not sure if I can prevent this problem without changes to Rails, unless perhaps I can find a way to load the real pg (if it is installed) from within my stub pg.rb. Thoughts?