Using the Subversion Ruby Bindings

I work with a distributed team of Ruby (on Rails) developers, and we use Subversion as our repository of choice. Just recently, I wanted to find out which files were recently changed or added to a particular directory of our project.

Doing it manually would’ve been tedious. I also wanted to do it with code so that maybe sometime in the future we might be able to script some behavior depending on the last changed date of a file or group of files in our repository.

I could’ve resorted to merely calling svn info and parsing its output, but I thought maybe this was a good excuse to sharpen my Ruby chops and figure out the Subversion Ruby bindings.

Using Rails console to copy records across databases

If you’re developing with Rails using PostgreSQL as your database back-end, you might find yourself in the same situation I was just in.

Rails, by convention, makes us think in terms of application ‘environments’: development, test and production (where I work we add “staging”). Each environment is given it’s own database (each environment can even have entirely different database servers).

During development, there’ll be times where you start populating a table with meaningful data as you develop and test. For example, you might have created a users table and added a couple of logins.

In some cases, data that’s meaningful in development can also be meaningful during staging or production. So, like me, one day you might find yourself wanting to copy some rows or an entire table from one database to another.

If I were using MySQL, I could easily do this via the SQL console. But PostgreSQL doesn’t support cross-database references (offering schemas, instead).

Fortunately, Rails comes with a nifty console which can do the job for us!

Bootstrapping your Database with Ordered Fixtures

Ruby on Rails provides a convenient way to ensure consistent database state for all unit tests and this is accomplished through Fixtures.

In the Rails Weenie forums technoweenie presented a technique that allows us to ‘bootstrap’ our development or production database using the same underlying mechanisms.

The way it works is first we place YAML files similar to the ones we use for testing under db/bootstrap (instead of test/fixtures). Then it’s a simple matter of executing:

rake db:bootstrap:load

Fixtures and Referential Integrity

The only problem with the above technique is when your tables have foreign key constraints (as they easily could if you use ActiveRecord Migrations with my own Migrations Constraints Plug-in).

When using fixtures for unit tests, we can explicitly specify the order of the fixtures in code. For example:

fixtures :foo, :bar_references_foo

The original technique by technoweenie allows us to specify a fixture order by an environment variable:

FIXTURES="foo bar_references_foo" rake db:bootstrap:load

While it works, it requires us to specify our fixture names and their order every time – not very DRY if you ask me.

Ordered Fixtures

Sandro Paganotti on RailsOnWave.com also realized this and presented his own version of rake db:bootstrap:load that attempts to address this.

The idea is to let us number our fixtures, similar to how we number our migrations, so that they can be loaded/unloaded in proper order according to our foreign key constraints.

Except, when I looked more closely at his code, I had my reservations.

First, and most glaring, is that he sorts the fixtures array, even if it’s passed in through the FIXTURES environment variable. I think this totally defeats the purpose of explicitly specifying the fixtures that way.

Second, and relatively minor, is that he hard-codes the format of the fixture file names so they have to be 2 digit numbers followed by an underscore, then the table name.

My rake db:bootstrap:load

So I set about to write my own, slightly more evolved version of Sandro Paganotti’s rake task.