Eager load application classes can block migration

Would someone please explain why this is wontfix? Or explain where I may be going wrong?

1) I create a new model with a class and migration 2) I run cap deploy:migrations 3) Capistrano runs rake db:migrate 4) Rails boots and tries to load_application_classes 5) Rails fails to load the new model class, since the table doesn't exist 6) The migration doesn't run

Sorry for the poor formatting there.

I've discovered how my environment (and that of the original poster) may be considered unusual: I have a plugin that adds functionality to my model, but must check #column_names to function correctly. So loading the class is enough to trigger checking the database, precipitating the SQL table-not-found exception.

I have a similar chicken and egg problem using ActiveScaffold with Rails 2.2.2. (IE, when trying to rake db:migrate, controllers get loaded, causing active_scaffold to try to reflect on the DB to get the model columns, but it can't because the DB table doesn't exist yet). It doesn't seem to happen when raking production, which is awfully odd, since I'm pretty sure my test and production environments are pretty similar....

to expand on ragaskar's point, it happends whenever config.cache_classes is on, which is typically production and test.

Yes, sorry, I've later confirmed that it does occur with prod AND test, or anywhere cache_classes is on.

For those looking for a workaround while waiting for a fix, this has worked for me:

config.cache_classes = (File.basename($0) == "rake" && ARGV.include?("db:migrate")) ? false : true

Pretty icky though.

Another workaround might be to have a separate environment with cache_classes set to false, but set to use the same database. Then you do

RAILS_ENV=production_no_cache rake db:migrate

I'm unfamiliar with the codebase specifically but I'm working on writing some failing tests...

So if the issue is with cache_classes, is this something that should be tested in migrations, in ActiveRecord, or in ActiveSupport?

I played around with the code, but I couldn't reliably reproduce the error because I'm not sure how to trigger the cache_classes event in the migrations tests... which leads me to believe it doesn't belong there.

BUT, it is an interesting problem because it occurs when loading classes that depend on column information that will exist after migrations run, etc...

What are thoughts on how to handle this?

(Sorry for the length... more or less rubber-ducking the problem to better understand.)

Looks like this problem shows up when using Ruport acts_as_reportable as well when RAILS_ENV is not development.

Will this fix be backported to 2.2 (please)?

On 2.3-RC1 having config.threadsafe!, and the fixes in http://github.com/rails/rails/co..., still causes the same issue. If config.threadsafe! is is commented out everything runs as expected.

@John Dell, this is the temporary fix we applied to our code until we upgrade to Rails 2.3

http://whatcodecraves.com/articl...

This fix may have been regressed. My current application is having the cached_class issue using Rails 2.3. The error occurs when running the migration rake task with an environment other than development:

$ rake db:migrate RAILS_ENV=test

The failure is the same chicken-egg problem where the model is attempting to access the database table before it has been migrated. Updating the cache_class setting in the test environment file fixes the issue.

Also of note is that we updated this application from Rails 2.2.2 and did run all the rails:update task when doing so. Thanks.

We had a similar issue and tracked it down to a badly behaving plugin that loaded the rails environment by itself prior to anything (that is: via require ...). Thus the whole environment was loaded before anything started and caused the break.
A properly behaving task will just depend on the :environment task instead of loading it itself (task :myplugin_task => :environment).
Hope that helps somebody.