Building Rails to Legacy Applications :: Take Control of Active Record

This post is part of my talk at OSCon 2006 entitled “Building Rails to Legacy Applications” Previously I showed you how you could use your database system to [http://people.planetpostgresql.org/xzilla/index.php?/archives/213-Building-Rails-to-Legacy-Applications-Masking-the-Database.html mask your schema] and present a Rails compatible version of your database to get started with the Ruby on Rails web framework. While this method has some advantages, it isn’t the only game in town. Today we will take a look at how to accomplish this task by taking advantage of some simple knobs and switches in Rails that let you use [http://en.wikipedia.org/wiki/Active_record Active Record] with non-standard schemas. We’ll again make use of the [http://pgfoundry.org/projects/dbsamples/ pagila database] for this example. If you went through part one, you can either drop all of the views we created before, or you can drop and reload your database. You’ll also need to move your old project out of the way, as we will want to make a new project to get things going: Once that is built, we need to modify the database.yml file to include something like this: The first thing in the Pagila schema that flies in the face of Rails Active Record format is that the tables all use a singular naming scheme, whereas Rails prefers plural naming. Because of this, the first thing we want to do is modify our Rails setup to not look for plural table names. This is done in the config/environment.rb file, where there are really a whole host of things you can modify, but for our needs we will just add the following line to the bottom of the file: Once that is done, we can go ahead and fire up the scaffolding to get some code in place. And just to verify, all of the files we would expect are in place: And with that, we have an actual working website: ID”, but our schema follows the naming convention of tablename_id. If you look in Rails console application, the problem is a little bit clearer: Between the error message and the sql statement, our problem becomes obvious, we don’t have the “id” column that Rails is looking for. Luckily, Rails gives us a way to work around this problem. To fix it, we just need to modify our model file for the actor table. As you can see, we can use the [http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000881 set_primary_key] method to easily designate any column as the primary key no matter what the naming scheme. More importantly, that’s all we need to do. Now we can restart our webserver and go on back to the website and it will “just work”. app/models/actor.rb with the following: And then generate the scaffolding for the Film table: And then also update our model for the film table with the same type of information in app/models/film.rb So what is this “has_and_belongs_to_many” thing all about? As the name indicates, this signifies that each actor can be in many films, and that a film can have many actors. Makes sense right? Let’s go to console to show our list of actors: What’s the problem? As the error message indicates, normally Active Record expects the many-to-many table that holds the relationship information to be named in an alphabetical manner; for example ”actors_tables” in our case. Of course Rails is very flexible, and gives us a way out of this problem: As you can see, we can specify the name of the join table, meaning you can adapt active record to any naming convention you might have. Of course we will also want to modify app/models/film.rb accordingly: And now to see it in action, let’s go back to console. So there you have it. There are actually many, many other little tweaks and knobs you can get into to make Active Record bend to your desires should you need them. You can peruse the [http://api.rubyonrails.com/ api documentation] if you like but generally I tend to wait to see if I run into trouble and then looking for the answer I need. Once you get past the first table or two though, you generally don’t need much more to get going.