About a year ago, file_column was one of the most popular plugin for storing files, particularly images, in rails applications. These days, the most popular plugin is Rick Olsen’s attachment_fu.

The main advantage of attachment_fu is it’s ability to store the files either on the file system, in binary fields in the database, or on amazon s3. The pluggable nature of the code also makes it fairly easy to support some other storage service.

I’ve avoided moving over because file_column actually provides more comprehensive image manipulation features, but there comes a time in the life-cycle of most applications where file system storage just doesn’t cut it in a multi-server environment.

There are already tutorials on using attachment_fu, I’m presuming that you already know how to use it. I’m just going to help you make the switch. Lets start with some code, here’s my migration for moving across the data:

class CreateProfilePhotosFromFileColumn < ActiveRecord::Migration
  def self.up
    for profile in Profile.find(:all)
      image_filename = select_value "SELECT image FROM profiles WHERE id = #{profile.id}" 
      unless image_filename.blank?
        image_path = RAILS_ROOT + "/public/system/profile/image/#{profile.id}/#{image_filename}" 
        image_file = File.open(image_path, 'r')        photo = ProfilePhoto.new(:profile_id => profile.id)
        photo.set_from_file(image_file)
        photo.save!
      end
    end
  end  def self.down
    execute "DELETE FROM profile_photos" 
  endend

In this example, I previously used file column in the field called “image” of my Profile model. Now, I have a new model called ProfilePhoto, which belongs_to Profile.

Although I’m happy to loop through all profiles using regular active record finders, note that I didn’t use the image method of profile. I know that after this works, I’m about to remove everything to do with file column, and so to play it safe, I use assert_select to fetch the file column image name directly from the database. This is ugly, but good policy in general for producing migrations that keep working after the code changes.

The other trick here is the call to “set_from_file”. This method doesn’t exist in attachment_fu, and was the first (of several) glaring omissions that I noticed in this plugin. To make this migration work, you’ll need to make a few changes to attachment_fu.rb yourself.

The following goes inside the InstanceMethods module:

def set_from_file(source_file)
  source_file_extension = File.extname(source_file.path).reverse.chomp('.').reverse
  source_file_name = File.basename(source_file.path)
  self.content_type = self.class.mime_type_from_extension(source_file_extension)
  self.filename = source_file_name
  self.temp_data = source_file.read
end

The following goes inside the ClassMethods module:

def mime_type_from_extension(extension)
  MIME::Types.type_for(extension).first.simplified
end

And the following goes at the top of the file:

require 'mime/types'

You’ll also need to “gem install mime-types”, although you will already have this if you installed the amazon s3 library.

This code is not hugely error tolerant. It presumes that all your records with file columns contain valid image files that are going to be accepted by your attachment_fu model. It also assumes that you set up attachment_fu correctly of course.

If it works, I would then add further migrations to remove the old file_column field from the Profile model, and to remove the file_column files themselves from the hard disk.

You’ll probably find the set_from_file method to be a valuable addition to attachment_fu for other purposes too. Our applications often receive their data in ways other than just HTTP post, and being able to save a file object seems like a pretty obvious addition.