| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Changes introduced in 7404cda9f61e41d52ce244d60abbf598684a96c4.
Fix railties build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 6acebb38bc0637bc05c19d87f8767f16ce79189b.
Usage of this feature did not reveal any improvement in existing apps.
Conflicts:
actionpack/lib/action_dispatch/routing/mapper.rb
guides/source/routing.textile
railties/lib/rails/engine.rb
railties/lib/rails/paths.rb
railties/test/paths_test.rb
|
| | |
|
| | |
|
| |
|
|
| |
Will show similar contents to the output of `$ rake routes` in the browser in development. This speeds the time required to generate routes, since the application is already initialized.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes route inspection in `rake routes`
Before:
foo /foo(.:format) :controller#:action"
After:
foo /foo(.:format) Redirect (301)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current router DSL, using the +match+ DSL
method will match all verbs for the path to the
specified endpoint.
In the vast majority of cases, people are
currently using +match+ when they actually mean
+get+. This introduces security implications.
This commit disallows calling +match+ without
an HTTP verb constraint by default. To explicitly
match all verbs, this commit also adds a
:via => :all option to +match+.
Closes #5964
|
| | |
|
| | |
|
| |
|
|
| |
production so that PID and timestamp are logged. fixes #5388
|
| |\
| |
| | |
[Proposal] Schema cache dump
|
| | | |
|
| |/ |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
of $rails_rake_task if it is already set.
Fixes #4591.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
through out the file
|
| |
|
|
| |
controller to be loaded.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If you used dynamic constraint like that:
scope :constraint => MyConstraint.new do
mount RackApp => "/foo"
end
routes were not displayed correctly when using `rake routes`.
This commit fixes it. If you want nice display of dynamic
constraints in `rake routes` output, please just override
to_s method in your constraint's class.
|
| | |
|
| | |
|
| |
|
|
| |
from Ruby stdlib.
|
| | |
|
| |
|
|
| |
reload_classes_only_on_change schema.
|
| | |
|
