Rails Ruby on Rails

Comments and changes to this ticket

• 

  josh November 22nd, 2008 @ 07:36 PM

  • State changed from “new” to “wontfix”

• You flagged this item as spam.
  

  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

• You flagged this item as spam.
  

  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 November 29th, 2008 @ 05:43 PM

  • State changed from “wontfix” to “open”

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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 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 December 16th, 2008 @ 10:17 PM

  • Milestone cleared.

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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:

  config.eager_load_paths.clear

• You flagged this item as spam.
  

  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 January 27th, 2009 @ 09:48 PM

  • State changed from “open” to “resolved”

  (from [f716ab92bf4872db635903f7b57f1c0d025e40a4]) Disable eager loading for all rake tasks [#802 state:resolved] http://github.com/rails/rails/co...

• You flagged this item as spam.
  

  spovich January 27th, 2009 @ 10:09 PM

  Will this fix be backported to 2.2 (please)?

• You flagged this item as spam.
  

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

  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.

• 

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

  • State changed from “resolved” to “open”
  • Assigned user set to “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.

  • migrations.zip 95.4 KB

• You flagged this item as spam.
  

  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

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

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.