| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`bin/setup` and `bin/update` are currently almost the same file. The
only thing that keeps them apart is that one is running `bin/rails
db:setup` and the other `bin/rails db:migrate`.
I'm suggesting here that they should be a unique script, which needs to
be idempotent.
- New to a project, need to get started? `bin/setup`
- Need to install new dependencies that were added recently? `bin/setup`.
Before deprecating `bin/update`, I'm suggesting we just have it call
`bin/setup`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cache versioning enables the same cache key to be reused when the object
being cached changes by moving the volatile part of the cache key out of
the cache key and into a version that is embedded in the cache entry.
This is already occurring when the object being cached is an
`ActiveRecord::Base`, but when caching an `ActiveRecord::Relation`
we are currently still putting the volatile information (max updated at
and count) as part of the cache key.
This PR moves the volatile part of the relations `cache_key` into the
`cache_version` to support recycling cache keys for
`ActiveRecord::Relation`s.
|
|\
| |
| |
| |
| | |
tjoyal/Rails/MailersController/do-not-leak-I18n-global-setting-changes
[Rails::MailersController] Do not leak I18n global setting changes
|
| | |
|
|/
|
|
| |
in void context
|
|
|
|
|
|
|
|
|
| |
This way, we only need to filter the backtrace up to the first non-noise
stack frame.
This also updates noise to be able to deal with being passed a lazy
enum. We don't need this anywhere, but it seemed better for this to be
consistent.
|
|\
| |
| | |
Remove `required: true` from the model generator template
|
| |
| |
| |
| |
| |
| |
| |
| | |
`belongs_to` association have `required: true` by default
https://github.com/rails/rails/pull/18937 onwards so we don't need it
in the generator template.
We still need the code for required in the command line generator as
it adds `null: false` in the migration.
|
|\ \
| |/
|/| |
Notes tags registration
|
| | |
|
| |
| |
| |
| |
| |
| | |
`test_app_update_does_not_change_config_target_version`
This is the follow up of 10fa3b3792153c2a213f837bcf51bbf6844c1661.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In `app:update`, it is decided whether to skip depending on whether
`Spring` is defined or not.
However, `spring` is not currently specified in Gemfile. As a result,
`app:update` determines that `Spring` is not used, and diff appears in
the result file.
If there is a difference, the console for processing the difference is
output and the test stops. To avoid this, do not include `Spring` in app.
This is a bit strange approach, so I will revisit this later.
|
|\ \
| | |
| | |
| | |
| | | |
ryohashimoto/do_not_app_update_in_app_generator_test
Do not execute `rails app:update` in railties/test/generators/app_generator_test.rb
|
| | |
| | |
| | |
| | | |
app:update` in app_generator_test.rb
|
| | |
| | |
| | |
| | |
| | | |
The mock is called three times because the `spring_install?` call has
been added in 65344f254cde87950c7f176cb7aa09c002a6f882.
|
| | | |
|
| | |
| | |
| | | |
It's unusable and not ready to ship in Rails 6.0. We'll rewrite it for 6.1.
|
|/ /
| |
| |
| | |
See rationale in the warning message included in the patch.
|
| |
| |
| |
| | |
For avoid to show `environment_desc` in help.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The original message from Zeitwerk is "can't reload, please call
loader.enable_reloading before setup (Zeitwerk::Error)", which is not
very informative for Rails programmers.
Rails should err with a message worded in terms of its interface.
|
| |
| |
| |
| |
| | |
It is necessary to run `rubocop` manually when new cop is added since
codeclimate checks any offences only in files touched in PRs.
|
|\ \
| |/
|/| |
Delete not user method for plugin_generator
|
| | |
|
|\ \
| |/
|/| |
Only override async adapter when seeding
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
We have `Style/RedundantBegin` cop (#34764) but it could not correct in
this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regression for fixture loading
d8d6bd5 makes fixture loading to bulk statements by using
`execute_batch` for sqlite3 adapter. But `execute_batch` is slower and
it caused the performance regression for fixture loading.
In sqlite3 1.4.0, it have new batch method `execute_batch2`. I've
confirmed `execute_batch2` is extremely faster than `execute_batch`.
So I think it is worth to upgrade sqlite3 to 1.4.0 to use that method.
Before:
```
% ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids
Using sqlite3
Run options: -n test_eager_loading_too_may_ids --seed 35790
# Running:
.
Finished in 202.437406s, 0.0049 runs/s, 0.0049 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 142.57s user 60.83s system 98% cpu 3:27.08 total
```
After:
```
% ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids
Using sqlite3
Run options: -n test_eager_loading_too_may_ids --seed 16649
# Running:
.
Finished in 8.471032s, 0.1180 runs/s, 0.1180 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 10.71s user 1.36s system 95% cpu 12.672 total
```
|
|
|
|
|
| |
* The fix is already in master since https://github.com/rails/rails/pull/34243
* See https://github.com/rails/rails/pull/35482 for the fix in Rails 5.2
|
|
|
|
|
| |
`original_app_name` is used to show error message if giving app name is
invalid, it should be shown raw app name.
|
| |
|
|\
| |
| | |
Add attachment and attachments field generators
|
| | |
|
|\ \
| | |
| | | |
Add db:prepare rake task.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Rename `connection` option to `database` in `dbconsole` command
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We introduced `connection` option for specifying spec with 1acd9a6464668d4d54ab30d016829f60b70dbbeb.
But now we are using the `database` to specify the same value in other commands.
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/migration/migration_generator.rb#L11
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/model/model_generator.rb#L17
The options provided to the users should be uniform. Since the term
"database" is used in rake task etc, So I want to be able to use it in
`dbconsole` command.
Also I deprecated the `connection` option because I think that it
would be confusing if there are multiple options to specify a same value.
|
|/ / / |
|
| | | |
|
|\ \ \
| | | |
| | | | |
url -> URL where apt except inside actionpack/
|
| | | | |
|