load_association_classes can block migrations (and slow down script/runner)

rubyonrails-core
1

Hello,

I ran into a problem recently that was previously reported as ticket #802 [1]. The issue, briefly, occurs when a model definition runs a class method (such as for a plugin) that checks table information. In this case, loading the model requires the database table to already exist. Running `rake db:migrate` in staging or production (anywhere with config.cache_classes=true) will then try and eager load all application classes, quickly failing with a table-not-found sort of error.

Also, the eager loading seems pretty detrimental any time Rails is booted from the console, such as via `script/runner` or `rake db:migrate`. Not only can it blow up because of an unmigrated database, but it incurs a pretty senseless performance hit for what may be a simple task. This could really hit applications that use BJ to run jobs in a full Rails environment, for example.

Does anyone have ideas how Rails might be smarter about when to eager load?

-Lance

[1] #802 Eager load application classes can block migration - Ruby on Rails - rails

2

Also, the eager loading seems pretty detrimental any time Rails is booted from the console, such as via `script/runner` or `rake db:migrate`. Not only can it blow up because of an unmigrated database, but it incurs a pretty senseless performance hit for what may be a simple task. This could really hit applications that use BJ to run jobs in a full Rails environment, for example.

Does anyone have ideas how Rails might be smarter about when to eager load?

This is something that's being worked on in edge rails at present. The goal is to move that preloading code to be as 'lazy' as it can be. The code still needs to fire in order to allow thread safe dispatching, but there's definitely no reason to do it for rake tasks, script/runner etc.

Josh and jeremy have been hacking away on it, perhaps they have something to add?