This project is archived and is in readonly mode.

#802 ✓resolved
Cyril Mougel

Eager load application classes can block migration

Reported by Cyril Mougel | August 11th, 2008 @ 09:39 PM

Since commit 89ec72c2:"" that add an eager loading in intializer, the execution of rake db:migrate in production mode with "config.cache_classe = true" can failed and block all migration.

If in a class Model, you use an ActiveRecord request to populate information in loading, the initialisation failed with this initialisation because there are no information in Database, because you want create it.

My case where I have this problem is with attachment_fu. In has_attachment, I made a request to Settings database. So it's failed in initialisation and I can't create database by rake db:migrate.

A solution is block the cache_classe during migration task, but I don't know how made otherwise update the production.rb file.

Comments and changes to this ticket

  • josh

    josh November 22nd, 2008 @ 07:36 PM

    • State changed from “new” to “wontfix”
  • cainlevy

    cainlevy November 29th, 2008 @ 01:06 AM

    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

  • cainlevy

    cainlevy November 29th, 2008 @ 01:21 AM

    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.

  • josh

    josh November 29th, 2008 @ 05:43 PM

    • State changed from “wontfix” to “open”
  • ragaskar

    ragaskar December 5th, 2008 @ 07:48 AM

    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....

  • gaffo

    gaffo December 16th, 2008 @ 02:30 PM

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

  • ragaskar

    ragaskar December 16th, 2008 @ 03:35 PM

    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.

  • Frederick Cheung

    Frederick Cheung December 16th, 2008 @ 07:08 PM

    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

  • Jeremy Kemper
  • Matt Todd

    Matt Todd December 25th, 2008 @ 08:26 AM

    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.)

  • Mike Williams

    Mike Williams January 6th, 2009 @ 10:47 AM

    • Tag changed from bug, eager_loading, edge, migrations, rake to bug, cache_classes, eager_loading, edge, migrations, rake

    I'm having the same problem, with ActiveScaffold, and Rails-2.2.2.

    Found a less icky work-around, though: disabling eager-loading of classes with:


  • Robert J Berger

    Robert J Berger January 19th, 2009 @ 08:10 PM

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

  • Repository

    Repository January 27th, 2009 @ 09:48 PM

    • State changed from “open” to “resolved”

    (from [f716ab92bf4872db635903f7b57f1c0d025e40a4]) Disable eager loading for all rake tasks [#802 state:resolved]

  • spovich

    spovich January 27th, 2009 @ 10:09 PM

    Will this fix be backported to 2.2 (please)?

  • Kenneth Kalmer

    Kenneth Kalmer February 15th, 2009 @ 08:39 PM

    On 2.3-RC1 having config.threadsafe!, and the fixes in, still causes the same issue. If config.threadsafe! is is commented out everything runs as expected.

  • Michael Koziarski

    Michael Koziarski February 15th, 2009 @ 10:14 PM

    • State changed from “resolved” to “open”
    • Assigned user set to “josh”
  • josh

    josh February 16th, 2009 @ 08:33 PM

    • State changed from “open” to “resolved”

    @Kenneth I can't reproduce the threadsafe! issue. I created a fresh rails app and it does not load any of the classes in the app folder (attached test app).

    If its still an issue on master please open a new ticket with more information about the error you received.

  • Jerry Cheung

    Jerry Cheung March 18th, 2009 @ 06:06 AM

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

  • Peer Allan

    Peer Allan July 21st, 2009 @ 04:27 PM

    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.

  • apeiros

    apeiros January 27th, 2010 @ 10:56 AM

    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.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>


Referenced by