Use the configured variable EXEEXT, instead of hardcoded suffix and
platform names.
And on such platforms, files which do not end with the suffix are not
executable, so the original names are not necessary, in general.
Before this change any error raised inside a transaction callback
are rescued and printed in the logs.
Now these errors are not rescue anymore and just bubble up,
as the other callbacks.
Introduce explicit way of halting callback chains by throwing :abort. Deprecate current implicit behavior of halting callback chains by returning `false` in apps ported to Rails 5.0. Completely remove that behavior in brand new Rails 5.0 apps.
Conflicts:
railties/CHANGELOG.md
Commit 1aea470 introduced this directory but this was at a time when the
default way to store sessions was on the file system under the tmp
directory.
Let's remove references to it from the documentation as well.
[Robin Dupret & yui-knk]
This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:
* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.
For this purpose, this commit introduces a Rails configuration option:
```ruby
config.active_support.halt_callback_chains_on_return_false
```
For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:
```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```
For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.
Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.
Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.
A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931
This commit modifies the code (but not the purpose) of a test that checks that
> initializers are executed after application configuration initializers
Currently the test hard-codes the *exact* initializers that are expected to
occur before a custom one. This can cause the test to fail even if the
expectation still passes.
This commit loosens the test by simply checking that, in the array of
initializers, the custom initializers (called `dummy_initializer` in the
example) is executed after the last occurrence of `load_config_initializers`.
Changes `rails g model Post user:references` from
def change
create_table :posts do |t|
t.references :user, index: true
end
add_foreign_key :posts, :users
end
to
def change
create_table :posts do |t|
t.references :user, index: true, foreign_key: true
end
end
Changes `rails g migration add_user_to_posts user:references` from
def change
add_reference :posts, :users, index: true
add_foreign_key :posts, :users
end
to
def change
add_reference :posts, :users, index: true, foreign_key: true
end
The changes in #18149 added tests for the app generator, but only fixed
it for the plugin generator (I should have let CI finish though I think
it would have failed as an allowed failure).
Closes#17945
`db:test:prepare` still purges the database to always keep the test
database in a consistent state.
This patch introduces new problems with `db:schema:load`. Prior
to the introduction of foreign-keys, we could run this file against
a non-empty database. Since every `create_table` containted the
`force: true` option, this would recreate tables when loading the schema.
However with foreign-keys in place, `force: true` wont work anymore and
the task will crash.
/cc @schneems
Fixes https://github.com/rails/rails/issues/17340.
Use Minitest::BacktraceFilter instead of removing all silencers. This
will allow the backtrace for all libraries in the plugin to be shown
while removing noise generated by Minitest's backtrace.
If you run a generator such as:
```
rails generate model accounts supplier:references
```
The resulting migration will now add the corresponding foreign key
constraint unless the reference was specified to be polymorphic.
This reverts deprecations added in #13528.
The task is brought back for two reasons:
1. Give plugins a way to hook into the test database initialization process
2. Give the user a way to force a test database synchronization
While `test:prepare` is still a dependency of every test task, `db:test:prepare`
no longer hooks into it. This means that `test:prepare` runs before the schema
is synchronized. Plugins, which insert data can now hook into `db:test:prepare`.
The automatic schema maintenance can't detect when a migration is rolled-back,
modified and reapplied. In this case the user has to fall back to `db:test:prepare`
to force the synchronization to happen.
This is a follow-up to 116de07. That change was for two reasons: 1) speed up the
tests by reducing the amount of log lines 2) avoid a deprecation warning from
a6de6f5.
This setting need to be on the basic app too, otherwise the deprecation warning
will show up on other unrelated test cases.
Currently, the docs uses a syntax that is unclear and not general
American English. I've switched it to be clearer wording. Not a big
fix, but may be helpful.
This is a more conservative approach to 2602a49. Also changed the comment to be
more inline with everything else in the file (describing what the config value
is doing and why). People should just read the docs for alternatives.
This reverts commit 2602a49a8600ab52f807599bbd5b1f9c0be4214f, reversing
changes made to 5d7c1057684c377bc2801c8851e99ff11ab23530.
The explicit default was introduced in 21f6d72, so apps created with Rails < 4
have the commented out version, which means that this change would break those
apps.
Renames `rake test:all` to `rake test` by changing old `rake test:run` to previous version of `rake test:all`. Removes old definition of `rake test`. Also renames `rake test:all:db` to `rake test:db` and deprecates `rake test:all` & `rake test:all:db`
Replaces the following in two places:
```diff
-require ::File.expand_path('../config/environment', __FILE__)
+require ::File.expand_path('../config/environment', __FILE__)
```
- `secrets.secret_token` is now used in all places `config.secret_token` was
- `secrets.secret_token`, when not present in `config/secrets.yml`,
now falls back to the value of `config.secret_token`
- when `secrets.secret_token` is set, it over-writes
`config.secret_token` so they are the same (for backwards-compatibility)
- Update docs to reference app.secrets in all places
- Remove references to `config.secret_token`, `config.secret_key_base`
- Warn that missing secret_key_base is deprecated
- Add tests for secret_token, key_generator, and message_verifier
- the legacy key generator is used with the message verifier when
secrets.secret_key_base is blank and secret_token is set
- app.key_generator raises when neither secrets.secret_key_base nor
secret_token are set
- app.env_config raises when neither secrets.secret_key_base nor
secret_token are set
- Add changelog
Run focused tests via
ruby -w -Itest test/application/configuration_test.rb -n '/secret_|key_/'
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
Performance optimization: `yield` with an implicit `block` is faster than `block.call`.
See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark:
```ruby
require 'benchmark/ips'
def fast
yield
end
def slow(&block)
block.call
end
Benchmark.ips do |x|
x.report('fast') { fast{} }
x.report('slow') { slow{} }
end
# => fast 154095 i/100ms
# => slow 71454 i/100ms
# =>
# => fast 7511067.8 (±5.0%) i/s - 37445085 in 4.999660s
# => slow 1227576.9 (±6.8%) i/s - 6145044 in 5.028356s
```
Since we want this flag to be enabled anytime we are running the tests
under JRuby, let's enable this at the Rakefile level so people get the
performance boost on their local checkout.
Moreover, we avoid having to update this particular line anytime the
option changes on the JRuby side.
The only drawback is that we have to define it in every Rakefile but
there's no big deal, this is already the case for other options.
Right now BenchmarkCleaner allocates hundreds of strings on every request with an exception. This patch moves those strings to be generated at boot once and re-used.
## Bench Methods
I took a modified form of CodeTriage https://github.com/schneems/codetriage-ko1-test-app/blob/master/perf.rake and ran given rake tasks with and without the patch to BacktraceCleaner.
I made an endpoint results in exception
```
def index
raise “foo"
end
```
The gem `memory_profiler` was used to capture objects allocated for a single request. Then `benchmark/ips` was used to test the speed of the patch.
You will see that we use less objects and the code becomes measurably faster with this patch.
## With patch:
Memory for one request:
```
Total allocated 7441
Total retained 37
```
Requests per second:
```
Calculating -------------------------------------
ips 4 i/100ms
-------------------------------------------------
ips 43.0 (±4.7%) i/s - 216 in 5.037733s
```
## Without patch:
Memory used for one request:
```
Total allocated 11599
Total retained 35
```
Requests per second:
```
Calculating -------------------------------------
ips 3 i/100ms
-------------------------------------------------
ips 39.4 (±7.6%) i/s - 198 in 5.052783s
```
## Analysis
The patch is faster:
```
(43.0 - 39.4 ) / 39.4 * 100
# => 9 # % ~ speed bump
```
It also allocates less objects:
```
11599 - 7441
# => 4158
```
These strings are allocated on __EVERY SINGLE REQUEST__. This patch saves us 4158 objects __PER REQUEST__ with exception.
Faster errors == Faster applications
fixture_path is a class attribute of ActiveSupport::TestCase, so
ActiveSupport::TestCase.method_defined?(:fixture_path=) would always
return false.
This should fix#4971
