We discussed that the auto explain feature is rarely used.
This PR removes only the automatic explain. You can still display
the explain output for any given relation using `ActiveRecord::Relation#explain`.
As a side-effect this should also fix the connection problem during
asset compilation (#9385). The auto explain initializer in the `ActiveRecord::Railtie`
forced a connection.
This reverts commit 304f4d4c25ccabdbf97d37dd7a92a54d0b63a9c9.
As it turns out everything should behave as it did and we don't
need to move this configuration option.
When we removed script/rails and introduced bin/rails, we accidentally
introduced a regression. If you install Rails 4 as a gem, then try to do
something in a Rails 3 application:
$ rails g
This will throw the 'please type rails new foo' message rather than the
proper generator documentation message. This is because older apps don't
have bin/rails.
Therefore, we now *prefer* bin/rails, but still search for script/rails,
and exec the one we find.
Most application developers shouldn't be adding paths to
`config.autoload_paths` as it won't be eagerly loaded so
remove it from the generated config/application.rb file.
If a developer does want to autoload from paths outside of the app
directory then they should add the path to `config.eager_load_paths`
as these paths are also autoloaded as well.
Whilst autoloading is known to be not threadsafe, leaving it in place
is a softer solution than failing hard when an application is deployed.
Many older applications will have paths added to `autoload_paths` and
ideally these should be eagerly loaded to be threadsafe. However one
of these paths is quite often lib which could lead to unintended
consequences due to the 'junk drawer' nature of this directory.
Developers should refrain from adding paths to `autoload_paths` or
`eager_load_paths` and use custom folders inside app for code that
needs to be eagerly loaded and use `require` or `require_dependency`
to explicitly load code from other locations.
Because of the possibility of lib being unintentionally eager loaded
it's been agreed that we'll leave autoload paths and eager load paths
separate for Rails 4.0.
This reverts commit 0757b3388ffe4f44b60de950d40e18ef05055931.
Conflicts:
railties/CHANGELOG.md
Print a message in both `rake routes` and at GET "/rails/info/routes"
that lets you know you have no routes defined, as well as linking to the
Rails Guide on the topic.
User should know that he can overwrite the previous migration. This
comes in handy especially when generating models which were previously
created then removed.
Speed up depends on the number of test phases (N) you have for your
app, but it is roughly a 1/N improvement. In my app, it goes from
15.51s to 5.56s.
Inspired by http://ngauthier.com/2012/02/quick-tests-with-bash.html
Reviewed by @tenderlove
Since the default in Rails 4.0 is to run in 'threadsafe' mode we need
to eager load all of the paths in `autoload_paths` so we alias
`eager_load_paths` to it. This may have unintended consequences if
you have added 'lib' to `autoload_paths` such as loading unneeded
code or code intended only for development and/or test environments.
If this applies to your application you should thoroughly check what
is being eager loaded.
