| 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.
|
| |
|
|
|
|
| |
Closes #7110 there's more work to do on rack-cache issue 69
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to do:
In your configuration:
Rails.queue[:image_queue] = SomeQueue.new
Rails.queue[:mail_queue] = SomeQueue.new
In your app code:
Rails.queue[:mail_queue].push MailJob.new
Both jobs pushed to the same default queue
Rails.queue.push DefaultJob.new
Rails.queue[:default].push DefaultJob.new
|
|
|
|
| |
this is so we can show route output in the development when we get a routing error. Railties can use features of ActionDispatch, but ActionDispatch should not depend on Railties.
|
|
|
|
|
|
|
|
| |
Since plugins were removed, we can clean up a few methods in engines.
We also use this opportunity to move `load_console`, `load_tasks` and
`load_runner` to Rails::Engine. This means that, if someone wants to
improve script/rails for engines to support console or runner commands,
part of the work is already done.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
railites_order method, introduced in 40b19e0, had a bug that was causing
loading application instance twice in initializers if railties_order
already included application instance. So for example
railties_order = [Foo::Engine, :main_app, Bar::Engine]
would result in such railties array:
[MyApp::Application, Foo::Engine, MyAppApplication, Bar::Engine]
In order to fix it, we need to check for existence of application in
both railties_order and railties arrays.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Remove deprecation warning of method redefined.
|
|
|
|
| |
queues
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[Closes #2507]
Changes:
* `Rails.initialized=` has been removed
* `Rails.initialized?` and `Rails.application.initialized?` are now
* delegating to `MyApp::Application.initialized?`
|
| |
|
| |
|
|
|
|
| |
[Carlos Antonio da Silva & Santiago Pastorino]
|
| |
|
|
|
|
|
|
|
|
| |
This makes rails behave properly when you serve static assets
and you have X-Sendfile headers enabled. Nevertheless in most
cases you should not rely on that and serve static assets with
a webserver like Apache or Nginx (as you already have it in
place anyway if you use X-Sendfile)
|
|
|
|
| |
https://github.com/rails/rails/pull/4470/files#r393461
|
|
|
|
| |
railties/lib/rails/application.rb
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This behaves similarly to REQUEST_URI, but
we need to implement it on our own because
REQUEST_URI is not reliable.
Note that since PATH_INFO does not contain
information about trailing question mark,
this is not 100% accurate, for example
`/foo?` will result in `/foo` in ORIGINAL_FULLPATH
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
replaced).
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
app_reloader_hooks.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
methods directly.
|
| |
|
|
|
|
| |
Rails::Application
|