Switching to test env doesn't set options correctly

[dhh]

The reset options don't make it from config.options.active_record to ActiveRecord::Base, says @josevalim.

[dhh]

Yeah, it seems like we need to run Rail.application.initialize! again after switching envs. But it's not built for that at the moment.

Is this something you can help with, @josevalim?

[josevalim]

I really think running on Rails.application.initialize! is sub-optimal because it was not designed to run more than once. There are plenty of scenarios where it can simply fail: for example, if you store the middleware stack in an instance variable (which is the case today), calling initialize! again won't fix it. We would need a way to tell that the data needs to be reloaded... and find all instance variables, caches and clear them up. That would definitely be cumbersome, prone to failure, etc.

My preferred solution would be to have a forked test process that we can rely on.

[josevalim]

Another advantage of having a separate test process is that we could detect if there any changes and create a new fork automatically. Today, if you change the config/application.rb, you would need to restart the console. If we maintain a fork, we may be able to do it automatically.

[dhh]

Can't we just blow away the Rails.application instance and set it up again? Rather than rerun the same instance?

It's a lot more complicated to fork before the Rails.application is setup up initially and then try to IPC with that fork.

On Dec 23, 2012, at 11:20 AM, José Valim notifications@github.com wrote:

I really think running on Rails.application.initialize! is sub-optimal because it was not designed to run more than once. There are plenty of scenarios where it can simply fail: for example, if you store the middleware stack in an instance variable (which is the case today), calling initialize! again won't fix it as well. We would need a way to tell that the data needs to be reloaded... and chase all instance variables, caches and clear them up. That definitely would be cumbersome, prone to failure, etc.

My preferred solution would be to have a forked test process that we can rely on.

—
Reply to this email directly or view it on GitHub.

[dhh]

This is too hard and not enough value. We'll just have you run another console session in the test env. JUDO!