models are not loaded in migrations when config.threadsafe! is set

the threadsafe option in production doesn't load the dependencies, you can configure it to load them with this option in your production.rb just after config.threadsafe!

config.dependency_loading = true

but I don't know how rails can behave with both options enabled in production

I'm pretty sure config.threadsafe! auto-requires all *.rb files it can find in your app on start up.

@thedarkone take a look at the threadsafe! source code:

# Enable threaded mode. Allows concurrent requests to controller actions and
# multiple database connections. Also disables automatic dependency loading
# after boot, and disables reloading code on every request, as these are
# fundamentally incompatible with thread safety.
    def threadsafe!
      self.preload_frameworks = true
      self.cache_classes = true
      self.dependency_loading = false
      self.action_controller.allow_concurrency = true
      self
    end

with dependency_loading = false rails doesn't autoload dependencies and models are a dependency of migrations

Automatic dependency loading is not thread safe, that's why it is being disabled.

Also checkout what happens in load_application_classes method if cache_classes is set to true.

Wouldn't that break lots of existing migrations?

What about making threadsafe! not be applied when doing migrations? Even if it's set in the config file. It really only benefits long-running apps, no?

Or could we even force a non-threadsafe environment for rake tasks? It doesn't make sense to be threadsafe there anyway.

heh.

lol, what a coincidence :).

"Wouldn't that break lots of existing migrations": No, why? I would only extend the text message of the 'no such constant' exception, of course only when the threadsafe option has been set. And perhaps only the first time.

Regardless, you said yourself it at least doesn't make sense. But it would make every migration that accesses a model invalid for any application that uses threadsafe!

hmm, I think I can't follow you? What exactly would make these migrations invalid? If they used to avoid that problem by explicitly require models then they shouldn't notice the difference. Or what do you mean?

What I mean is that right now, people are writing migrations that access models. I've done it myself when using a legacy database to get a table name, ex. add_column Person.table_name, ... or maybe to repair some inconsistent data put in by a bug, like orphaned or duplicate rows.

What it comes down to is whether the solution is to make people require models in migrations, or make migration loading work in migrations (when threadsafe! is on). I would say that being able to access models in migration is reasonable, and being widely used right now, so the proper way to fix this is to make model accesses work in migrations. The simplest way I can think of to do that is to disable threadsafe mode when migrating somehow.

Of course, an explanation in the error message is better than nothing though.

I'm experiencing this behavior with rake tasks as well. This would seem to be more problematic since there's no philosophical opposition to referencing models within rake tasks?

My specific scenario is that I have a rake bootstrap task that sets up some default system data. Even when depending on the :environment task to load everything up for me, my models aren't found within the rake task unless explicitly required. Disabling config.threadsafe! fixes the reference issues.