Head London

Installing Phusion Passenger on Centos With a Custom Apache2

We’re currently running Apache2 on an old (and very stable) version of CentOS. It’s so ancient it didn’t come with Apache 2, so we’ve got it installed from source. Today we’re making the big move to running our Rails apps on Phusion Passenger (a.k.a mod_rails), but we ran into some problems with the compilation of the Apache module, mainly because passenger-install-apache2-module couldn’t figure out where any of the Apache development headers were. It’s a great installer but it can’t magically figure out where Apache’s keeping its development headers.

The solution was pretty simple, extracted from here and boiled down, it’s:

[code]export APXS2=/usr/local/apache/bin/apxs
export APR_CONFIG=/usr/local/apache/bin/apr-1-config[/code]

You may need to change the path depending on where you’ve got Apache installed.

Posted by Dave Hrycyszyn in All, Head Labs | No comments yet, why not add one?

Testing Single Table Inheritance Models in Ruby on Rails

I had a small problem today when trying to do unit testing of single-table inheritance models in Rails, all my tests initially failed and I wasn’t quite sure why. It’s a pretty simple fix but isn’t documented too well anywhere, so here’s the skinny.

My model structure was pretty simple, I had a Content class that acted as a base class for Article, Page, Event, and a bunch of others. So I added a Content class using a model generator, ending up with:

[code]
class Content < ActiveRecord::Base
end
[/code]

Then I added Article and Page classes using the model generator, and changed the default class definitions so that each of those classes inherited from Content. That looks like this:

[code]
class Article < Content
end

class Page < Content
end
[/code]

Then I ran my tests, expecting that the default “test_true” assertions were going to pass. Explosion!

The first problem was that I named my table “content”, not “contents”. Since this isn’t included in the pluralization rules for Rails, my model was trying to find a table called “contents”. This was easily fixed by changing the Content class like this:

[code]
class Content < ActiveRecord::Base
set_table_name "content"
end
[/code]

However, tests were still failing. After quite a bit of googling, it turns out that it was the auto-generated test fixture names that were the problem. First off, the articles.yml and pages.yml file were useless – when testing STI classes, you set up your fixtures in the superclass fixture definition. That is, in my case I only needed content.yml, and if I wanted to set up an Article fixture in there, it would look like this:

[code]
article_one:
id: 1
title: foo
body: this is a body
type: Article
[/code]

Note that I had to set the type property manually to the class name of the subclass object that the fixture is for. Note also the name of the fixtures file – because of my use of a table name for Content that’s not in the default pluralization rules, the fixture file needed to be content.yml rather than the default contents.yml.

One more thing and it all fell into place. All of the generated unit tests had incorrect fixture file names in them – content_test.rb had fixtures :contents, article_test.rb had fixtures :articles, and page_test.rb had fixtures :pages. All of these needed to be changed to fixtures :content before any of the tests would work. Rails apparently looks for a database table name matching the name of the fixtures file, so until I did this my tests were failing when looking for nonexistent tables.

Hopefully that will save someone from the horror of having to trawl the web using the keywords rails sti test.

Posted by Dave Hrycyszyn in All, Head Labs | 6 comments so far.