Question

This is a convoluted example so bear with me:

I have a script that I routinely use during dev that will wipe out my tables of my dev and test databases, remigrate, then reseed them. Due to my use of triggers in a couple places, I’ve had to use rake db:migrate RAILS_ENV=test to migrate my test database properly.

Everything was fine until I turned config.cache_classes=true on in my test environment. Then when the rake migration ran on an empty database I would get an error about how the table doesn’t exist. Running this with a –trace, I find that its blowing up on one of my objects when it declares a basic scope:

scope :find_by_route_and_date, lambda { |route_id, date|
    {
      :conditions=>{:route_id=>route_id, :schedule_date=>date}
    }
  }

The scope is in a lambda, so it shouldn’t be getting evaluated, but the minute I remove cache_classes, the migration works fine. So, to me it seems like its trying to cache the model, choking on the scope because the table doesn’t exist yet, and never starting the migration.

Am I losing my mind? Anyone else seen this? If I need to wipe my db, do I need to turn caching off, then migrate, then turn it back on?

Rails 3.2, ruby 1.9.2, rake 0.9.2.2

UPDATED:

As requested, here is the stack trace: https://gist.github.com/1705064

The order.rb:179 is the place where my first scope is defined and where it blows up that I listed above.

Answer 1

This is interesting. My reading of the stack trace is that rails is trying to help you be seeing if whether creating that scope (ie creating a method of the same name) you would be creating trouble by overwriting some existing method.

This leads active record down respond_to where it thinks that your scope/method name looks a lot like a dynamic finder. It then goes further: as well as looking like a dynamic finder, do all the named attributes exist? This is where it tries to check what columns the non existant table has and everything blows up.

You could (I think) do one of a few things:

• before the scope, define a class method with the same name as the scope so as to short circuit the respond_to call (yuck)
• change your scope name
• override valid_scope_name

I’m still not sure why you can’t setup the test db from a schema file, if necessary setting the schema dumper to :sql so that things that active record doesn’t support natively are preserved.