I've noticed a caveat with the :autosave option biting people before.
Questions arise about why they must explicitly save an associated object
in their own before_save callbacks. I've updated the documentation as
such to note to users that the :autosave callback occurs before any
user defined callbacks. They must save the associated record themselves
if altering it in their own callbacks.
Signed-off-by: David Celis <david@davidcelis.com>
This reverts commit b0ab8dc0b2b0f580ffe5ac9ff57fd13152e18577
because it was removing the contents of the message when we
did not have any tag. A test case is also committed.
The reason the test was failing was because when the test
invokes `app.config`, the app is loaded and, as `eager_load`
is set to true, it disables the dependency loading mechanism,
so controllers that are later defined are not loaded.
The revised test assumed that the default permissions of a file
matched the umask of the process, but in the general case that
depends also on the file system. This test was failing in the
/vagrant shared folder of Rails development boxes.
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
Previously, ActiveSupport::Autoload was global and reserved
for usage inside Rails. This pull request makes it local,
fixes its test (they were not being run because its file
was named wrongly) and make it part of Rails public API.
The flag was mainly used to add a Rack::Lock middleware to
the stack, but the only scenario the lock is desired is in
development.
If you are deploying on a not-threaded server, the Rack::Lock
does not provide any benefit since you don't have concurrent
accesses. On the other hand, if you are on a threaded server,
you don't want the lock, since it defeats the purpose of using
a threaded server.
If there is someone out there, running on a thread server
and does want a lock, it can be added to your environment
as easy as: `use Rack::Lock`
Previously, the eager load behavior was mostly coupled to
config.cache_classes, however this was suboptimal since in
some environments a developer may want to cache classes but
not necessarily load them all on boot (for example, test env).
This pull request also promotes the use of config.eager_load
set to true by default in production. In the majority of the
cases, this is the behavior you want since it will copy most
of your app into memory on boot (which was also the previous
behavior).
Finally, this fix a long standing Rails bug where it was
impossible to access a model in a rake task when Rails was
set as thread safe.
Change mysql tests for strict mode disabled to work with new sql_mode default in MySQL 5.6.6-m9.
Since this MySQL version, the sql_mode default value is `NO_ENGINE_SUBSTITUTION`.
Reason since MySQL 5.6.6-m9 the `sql_mode` default value is
`NO_ENGINE_SUBSTITUTION`.
This default parameter change is out of control from Rails.
This test verifies Rails not overriding the default `@@GLOBAL.sql_mode` value
by checking if `@@GLOBAL.sql_mode` is the same as `@@SESSION.sql_mode`.
