Ryan's Scraps

There are a plethora of fixture plugins that attempt to make your test fixtures less of a pain in the arse to work with. And most do succeed in one manner or another.

Well one of the nicest fixture plugins, called Rathole, has just been sucked down into rails – and it’s a doozy. Let’s summarize so you can decide whether to dive in or not.

Let’s use the following model for this example:

1
2

class Company < ActiveRecord::Base; has_many :employees; end
class Employee < ActiveRecord::Base; belongs_to :company end

Just a simple one-to-many association between a company and its employees, easy enough. But when we get into setting up our fixtures there’s a lot of non-essential stuff and easy to mess up ids we have to manually specify. And all this just gets exponentially hairier as the data-set increases.

1
2
3
4
5

yfactorial:
  id: 1
  name: yFactorial, LLC
  created_at: <%= Time.now %>
  updated_at: <%= Time.now %>

1
2
3
4
5
6

ryan:
  id: 1
  name: Ryan Daigle
  company_id: 1
  created_at: <%= Time.now %>
  updated_at: <%= Time.now %>

With Rathole’s features you no longer need to manually reconcile the cross referenced ids and to set the auto-magic date column values. Watch carefully what your fixtures can be when they grow up:

1
2

yfactorial:
  name: yFactorial, LLC

1
2
3

ryan:
  name: Ryan Daigle
  company: yfactorial

• You no longer have to specify the id for each record. That’s automatically done for you as the hash of the name of the record (so the integer hash of "yfactorial" becomes that record’s id)
• No need to specify the auto-magic date field values anymore. All the created_xx and updated_xx fields will be automatically populated with Time.now
• When referencing other record ids (as in employees.company_id), you can just put the fixture name and it will resolve that column to be the pk value of the referenced record. This is what allowed me to change the company_id: 1 line in employees.yml to be company: yfactorial.

Note: Since the primary keys of each record are calculated (as a hash of the fixture name), the fixture doesn’t need to be loaded before knowing what it’s pk value will be. This resolves a lot of the recursive dependency and ordering issues you might’ve otherwise encountered with an approach such as this.

But there’s more… Foreign key references get especially twisted when you have join tables that govern your has_and_belongs_to_many associations. So assume a company has_and_belongs_to_many industry_associations:

1
2
3
4
5
6
7
8

class Company < ActiveRecord::Base
  has_and_belongs_to_many :industry_associations,
                          :join_table => 'company_industry_associations'
end
class IndustryAssociation < ActiveRecord::Base
  has_and_belongs_to_many :companies,
                          :join_table => 'company_industry_associations'
end

Instead of having to write our own company_industry_associations.yml fixture file, we can just reference the collection of associations a company belongs to inline in companies.yml:

1
2
3

yfactorial:
  name: yFactorial, LLC
  industry_associations: ruby, webservices

Assuming there’s an industry_associations.yml fixture file that specifies records named ruby and webservices, the habtm join table will be automatically populated for you.

This is a really big win for you fixture users (of which I am one). Perhaps those that have turned their nose up at fixtures will take a second look? Really great functionality – thanks, John, for the contribution!

Take a look at the bottom of the plugin’s README file to see how to setup default values and how to fetch the pks of other fixtures

tags: ruby, rubyonrails

Controller filters just got a little update that may mess with your flow. As of now, returning false no longer halts the execution of the action chain. Instead, rendering or redirecting is what automatically stops the action chain.

If you think about it, it makes sense that rendering or redirecting within a filter signals the abortion of normal action execution since you can only render/redirect once per call and doing so reasonably indicates that no more processing is required.

So where before you might have had a filter such as:

1
2
3
4
5
6

def must_be_logged_in
  if(not user_logged_in?)
    redirect_to login_url
    return false
  end
end

You can now let the act of rendering or redirecting imply completion instead of returning false:

1
2
3

def must_be_logged_in
  redirect_to login_url if not user_logged_in?
end

At first blush I thought this might mess up existing filters, but a quick review of mine indicated that whenever I return false I’ve already rendered or redirected. Not sure if this holds true for everybody or not…

tags: ruby, rubyonrails

Want a chance at a free copy of this Rails 2 mini-book? See how here.

Let’s face it, if you read this blog you don’t do it because of my extreme intellect or witty composition. You’re here because you want to know what stuff is makings its way into Rails.

With the impending release of Rails 2 you could spend all day scouring this site and the blogosphere to collect all the cool new stuff in Rails 2 from outdated posts … or you can head on over to Peepcode press and pick up my brand spankin’ new Rails 2 mini-book which collects all the new features in Rails 2 for you.

Deterred by the obvious lack of skill in my normal blogging? Then take a peek at the free preview to see if it meets your snooty standards before you drop any cash.

This is my first publication of any kind and can I tell you how great it is to be a part of the family of high-quality publications put out by Peepcode. If you haven’t heard of them yet – do yourself a favor and head over to check out both their screencasts and DRM-free mini-books.

Drop me a line if you have any corrections or comments to the book that you don’t want the world to see. Otherwise, comment away here.

tags: ruby, rubyonrails

The Rails 2.0 preview release is here. Go get ya some

svn co http://svn.rubyonrails.org/rails/tags/rel_2-0-0_PR

tags: ruby, rubyonrails