Catch-22: Rails db migration doesn't run when class constants make db calls

Question

I have a class similar to the following:

class FruitKinds < ActiveRecord::Base
  Apple = FruitKinds.find(:all).find { |fk|
    fk.fruit_name == :apple.to_s
  }

  # ... other fruits

  # no methods
end

Apple and other specific Fruits are commonly used as default values elsewhere in my application, so I want a handy means to refer to them in an enumerable, static-ish way.

However, there's a problem. There is a database migration to create the FruitKinds table and populate it with the special Fruits like Apple. When the database migration runs to initialize FruitKinds, rake fails to start because it first loads FruitKinds, which then makes a call to the database, which of course fails since the FruitKinds table is not yet there.

The workaround is to comment out the FruitKinds::* fields while the migration runs, but that is awful and hacky. What's the best way to do this?

Answer 1

That's a pretty common gotcha, to the point that I now consider any database access at the class definition level an antipattern. The alternative is to make it a lazy property. The simplest way to do this is simply to make it a class-level method instead of a constant. Note that you can have capitalised methods in Ruby, so you can make it look like a constant if you want:

class FruitKinds < ActiveRecord::Base
  def self.Apple 
    @apple ||= FruitKinds.find(:all).find { |fk|
      fk.fruit_name == :apple.to_s
    }
  end

  # ... other fruits

  # no methods
end

Or if you want to get fancy you can use const_missing to dynamically create the constant the first time it is accessed.

As a side note, that's about the most inefficient way possible to find a record by name ;-)

Answer 2

As Avdi mentioned, you'll want to avoid interacting with the database when the class is loaded. If you're wanting to cache database records in local memory, I recommend using the Memoization feature added in Rails 2.2. See my post here for details.