*sigh* this seems like the never ending bug. I don't love or even like
this fix but it does _work_.
Rafael suggested using `dummy_key: dummy_value` but unfortunately
that doesn't work. So we're left with checking whethere there might be
ternary type things in the content and then assuming that we want to
replace the line with a key value pair.
Technically fixes https://github.com/rails/rails/issues/36088
The virtual attributes(`attachment` and `rich_text`) can't set value
with `fill_in`. So avoid using it. Once #35885 is merged, will be
modified to use it.
Also, add checking attachment attached or not for avoiding
`DelegationError` when attachment didn't attach.
As suggested in https://github.com/rails/rails/issues/35602#issuecomment-485833483, because we don't provide view caching and doesn't include `ActionController::Caching` for api apps, we should also avoid generating
```ruby
config.action_controller.perform_caching = true
```
for those api apps. So it won't confuse people.
**But because `perform_caching` will be `true` if not set, the behavior of the app would still be the same without these configs.**
This commit more or less undoes 9b5401f, restores autoloaded? not to
touch the descendants tracker, and autoloaded_constants because it is
documented in the guide.
Previously we were calling the `take_failed_screenshot` method in an
`after_teardown` hook. However, this means that other teardown hooks
have to be executed before we take the screenshot. Since there can be
dynamic updates to the page after the assertion fails and before we
take a screenshot, it seems desirable to minimize that gap as much as
possible. Taking the screenshot in a `before_teardown` rather than an
`after_teardown` helps with that, and has a side benefit of allowing
us to remove the nested `ensure` commented on here:
https://github.com/rails/rails/pull/34411#discussion_r232819478
With 8b4d344815655027d9f7584c0a59271dce8f1d5a, `test_required_polymorphic_belongs_to_generates_correct_model`
and `test_required_and_polymorphic_are_order_independent` are completely
same. Also, remove `required` from test name because that not passed to
generator.
This change adds the ability to run up/down for a database in a multi-db
environment.
If you have an app with a primary and animals database the following
tasks will be generated:
```
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:down:primary
VERSION=123 rake db:migrate:up:animals
```
I didn't generate descriptions with them since we don't generate a
description for a single database application.
In addition to this change I've made it so if your application has
multiple databases Rails will raise if you try to run `up` or `down`
without a namespace. This is because we don't know which DB you want to
run `up` or `down` against unless the app tells us, so it's safer to
just block it and recommend using namespaced versions of up/down
respectively.
The output for the raise looks like:
```
You're using a multiple database application. To use `db:migrate:down`
you must run the namespaced task with a VERSION. Available tasks are
db:migrate:down:primary and db:migrate:down:animals.
```
- Also deprecate passing {required} to the model generator.
- Also made sure the global config `belongs_to_required_by_default` is
applied correctly to the model generator for `null: false` option.
Currently ActionController::API doesn't include Caching module, so it
can't perform caching. And even if users include it later manually, it
won't inherit application's default cache store for action_controllers.
So the only way to solve this issue is to include Caching module in
ActionController::API, too.
This closes#35602
`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`.
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.
`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.
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.
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.
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
```
