Upgrading your Rails 1.1 application to Rails 1.2

So, I’m in the process of getting our servers upgraded to Rails 1.2.

( We don’t freeze rails, because contrary to the cult of Rails, freezing is not the way to go in small, controlled shops with multiple applications. If say, you have to upgrade your Rails, NOW NOW NOW – it’s much better to upgrade the system, and not every copy of your application everywhere, but I digress)

That process, of course, involves making sure our applications work with Rails 1.2 and eating my own dog food – this is what a cursory run through of the application that I’m responsible for had me running into:

Deprecations

The biggest issue – which really isn’t an issue, which was cool – seems to be the deprecations coming in Rails 2.0. But for anyone playing along with the home game – deprecations are errors. (maybe I should start a “Cult of the Clean Log”).

The deprecations I had:

  • multiple references to @request, @params, @session…
  • references to @flash, including a really odd error that resulted from the fact that I had a partial named “_flash.rhtml”. Thankfully I wasn’t the only person that ran into that
  • a lot of start_form_tag and end_form_tag references. And while I to this day get a little squicked out by phrases like “syntactic sugar/vinegar” – I do very, very much like the block form for <% form_tag(:action => :blah) do %> ... <% end %>

Aggressive Unloading

In the famous words of Keith Jackson:

“Whoa, Nellie!”

So we are probably doing something incredibly stupid and against every known convention of Ruby and Rails – but, hey, it works. We have an class for application configuration that we use a class variable to store persistent configuration information (with a default set of values, merged with values loaded from a configuration file where appropriate). Prior to now, we’ve happily loaded this up on application startup in environment.rb to load the configuration – and even in development mode, the class stayed loaded throughout the lifetime of the mongrel process.

Well, apparently in development mode in Rails 1.2 – the automagic dependency management has significantly changed (ob. ref. Jonathan Weiss and the RoR weblog. That’s cool, it’s probably what it should be, and what I’m doing in this application probably isn’t “the right thing.” But the AppConfig class would unload, and be reloaded and because the load_config method was only called in environment.rb, it was Oops’ing all over the place. My hack was to load the config within the body of the class, so it would do it when the class was loaded (loaded might not be the right word here). If I continue with this AppConfig thing – what it probably should be doing on accessing the configtable is to have checks that when it’s nil – reload the config. I’ll solve that one later, thankfully for now, it works again.

If any Rails person that actually reads this has any kind of visceral – “why the heck do you guys do that?!?” – reaction – and know a better way of doing this (the whole persistent configuration-defined-at-run-time-not-in-code-or-the-db problem) please do share.

A HUGE “thanks!” to the Rails team for including Dependencies.log_activity = true as part of dependencies.rb. That helped a lot – and helped provide a glimpse into the automagic dependency management of Rails too.