| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
railties/test/application/configuration_test.rb
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
manifest path.
This option is now unsupported in sprockets-rails.
|
|
|
|
| |
option added (default is Monday)
|
| |
|
| |
|
|
|
|
|
|
| |
Tell people to install `activerecord-session_store` gem when it's not
installed instead ofraising `NameError` on missing
`ActionDispatch::Session::ActiveRecordStore`.
|
|
|
|
|
| |
This functionality will be available from gem
`active_record-session_store` instead.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
|
|
|
|
|
| |
Also make sure to not use default queue consumer with custom queue
implementation. It is up to the new queue implementation to
start / shutdown the consumer.
|
|
|
|
| |
consumers around stdlib's Queue
|
| |
|
| |
|
|
|
|
| |
production so that PID and timestamp are logged. fixes #5388
|
| |
|
|
|
|
| |
the update action of resources
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PATCH is the correct HTML verb to map to the #update action. The
semantics for PATCH allows for partial updates, whereas PUT requires a
complete replacement.
Changes:
* adds config.default_method_for_update you can set to :patch
* optionally use PATCH instead of PUT in resource routes and forms
* adds the #patch verb to routes to detect PATCH requests
* adds #patch? to Request
* changes documentation and comments to indicate support for PATCH
This change maintains complete backwards compatibility by keeping :put
as the default for config.default_method_for_update.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds ability to set custom console if you want to use
something other than IRB. Previously the hack that people used
was:
silence_warnings do
require 'pry'
IRB = Pry
end
which is not the best way to customize things.
|
| |
|
| |
|
| |
|
|
|
|
| |
through out the file
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
instance, hooking on fsevents).
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c2e3ce8d1e1174e66536d59d8d97eb2cc8ce6f25.
Conflicts:
railties/lib/rails/application/configuration.rb
railties/lib/rails/application/finisher.rb
railties/lib/rails/engine.rb
|
|
|
|
|
|
|
|
| |
This can be turned off by setting `config.reload_classes_only_on_change` to false.
Extensions like Active Record should add their respective files like db/schema.rb and db/structure.sql to `config.watchable_files` if they want their changes to affect classes reloading.
Thanks to https://github.com/paneq/active_reload and Pastorino for the inspiration. <3
|
| |
|
| |
|
| |
|
|
|
|
| |
production concerns
|