Yesterday, DHH said:

“I’d love for Rails to be easy as pie to run in a shared hosting environment, though. I’d love for Rails to be easy as pie to run in any environment. In that ‘more people could have fun learning Rails and deploying their first hobby application’ kind of way.”

We humbly suggest that Heroku is one possible solution to the latter part of statement. Our vision for the long term is much grander than just a learning/hobby tool; but our beta product, as it stands today, can already fill this need quite nicely.

Rails 1.2 is now officially deprecated for Heroku apps. Starting January 3 (that’s tomorrow), new features we are developing will not be available on apps still configured to use Rails 1.2. Then, on January 21, we will automatically upgrade any remaining 1.2 apps.

We know it’s only been a month since Rails 2 came out, so we hope this doesn’t come across as overly harsh. By taking this approach we can spend less time backporting, which means more time for new features. Since Heroku is still in early beta we feel that this is reasonable. Rest assured that when the next major Rails release comes around, we’ll be committed to supporting 2.0 for a much longer time window.

In most cases, upgrading should be as easy as changing your `config/environment.rb` to contain 2.0.2 instead of 1.2.x, and adding a block that looks like this to your initializer:


config.action_controller.session = {
:session_key => '_my_app_session',
:secret => '241b740a2f480d9776e6ce0c36b51f9df46ecf1d25814cd03b4d14dbb6ba7cd92'
}


If you find that you have breakage after the upgrade, read this post by Steve Ross which covers potential areas of incompatibility in detail.

And if you’re still having difficulty with the upgrade, just send us an email with the name of your app and we’ll be happy to help.

Rails 2 is now the default for all newly created Heroku apps.

Existing apps will continue to run on 1.2 unless you edit config/environment.rb and change the version number manually. Importing an app will try to guess the Rails version from your environment.rb, but you should double-check after the import to make sure the version is set to what you wanted.

We’ll leave a 1.2 gem available for a while, but we’re going to take advantage of our beta status here and keep the time window on this relatively short – perhaps a month or two. (Don’t worry, by the time the next major Rails release goes around, we’ll have a plan for longer-term support of legacy versions in place.)

It’s quite painless to upgrade, especially if you don’t have any deprecation warnings in your logs. Here’s a list of the major features and changes, and here’s some notes to help you upgrade.

One of the many benefits of Rails is database independence. Migrations are particularly nice in this regard; and the easy-to-read / Rubyified display of your schema (via rake db:schema:dump) in schema.rb is icing on the cake.

But what about data? For import and export of the actual data, we’re stuck with mysqldump (or pg_dump, if you’re so inclined). Further, these dump formats are not terribly readable, contain lots of information you may or may not want to copy (like permissions, schema settings, views, triggers…you know, database features that Rails users are supposed to avoid).

Worst of all, ddata dumps are vendor specific, so you can’t move data between databases (e.g., SQLite, MySQL, PostgreSQL). Rails is database-independent, but you’re pretty much stuck with whatever you picked at the start of the project. That’s hardly agile.

Realizing this problem was going to affect us in a pretty direct way with the import/export features of Heroku, Orion and I threw together a plugin yesterday which we’ve given the (rather uninspired) name YamlDb. Once you’ve installed it:

script/plugin install http://opensource.heroku.com/svn/rails_plugins/yaml_db

...you’ll have the additional rake tasks db:data:dump and db:data:load, which access a file data.yml. This is a simple dump of your database’s tables, which along with schema.rb, describe everything you need to make a complete copy of your database. (db:dump and db:load are shortcuts to do both schema and data together.)

What’s awesome about this is that you can switch databases in the blink of an eye. Got a SQLite3 database that’s gotten too big for its britches? rake db:dump, create a MySQL database, update your config/database.yml, and rake db:load. Presto, your app is now running in MySQL. Want to give PostgreSQL a try? Same process. Run it for a week, and decided you miss mysqladmin too much? Reverse the process, bringing the data which was stored in Postgres during that week back into MySQL.

Caveats: it’s much slower than dumping and restoring with your database’s native tool, and probably will stop working altogether with a database that is larger than RAM. But for most apps it should work fine. In the future we will most likely write database-specific extensions to make dump/restore process happen in chunks, and thus be more scalable.

As for Heroku, it now uses yaml_db as its native import/export format. So when you export an app from Heroku, you’ll always see a db/data.yml with your current data. It also makes it easy to import data into your Heroku app, at the same time you’re importing the code, or later on. Just install yaml_db in your app locally and run db:dump. Include data.yml with the import (or run and upload it separately), and then run db:load at the rake console.