https://github.com/rails/rails/pull/42601 fixed clearing the inverse relation,
but it didn't account for collection associations.
For these, just assigning `nil` isn't possible because we need the record to
remove it from the collection.
So this PR introduce an explicit method for this purpose rather than
reuse `inversed_from(nil)`.
When writing fixtures, it's currently possible to define associations that don't exist, even if a foreign key exists. For example:
```yml
george:
name: "Curious George"
pirate: redbeard
blackbeard:
name: "Blackbeard"
```
When the fixtures are created, `parrots(:george).pirate` will be nil, but it's not immediately clear why. This can make it hard to debug tests and can give false confidence in passing ones.
This can happen because Rails [disables referential integrity](f263530bf7/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb (L407)) when inserting fixtures. This makes the fixtures algorithm much simpler - it can just create the fixtures in alphabetical order and assume that the other side of a foreign key constraint will *eventually* be added.
Ideally we would check foreign keys once all fixtures have been loaded, so that we can be sure that the foreign key constraints were met. This PR introduces that. To enable it:
```ruby
config.active_record.verify_foreign_keys_for_fixtures = true
```
I'm proposing we enable this in 7.0 for new apps and have added it to new framework defaults. When run against our app, it found 3 fixture files with unmet FK constraints - turns out all those fixtures weren't being used and were safe to delete.
`railties/lib/rails/application/configuration.rb` contains defaults that
haven't been added to the `new_framework_defaults_7_0.rb.tt`.
This adds these defaults to ease migration.
Framework defaults cause confusion for contributors when adding new
defaults. Should the defaults be defined in:
`railties/lib/rails/application/configuration.rb` and/or
`config/initializers/new_framework_defaults_7_0.rb.tt`
And should these define the new or old defaults?
Hopefully this clarifies it by making it clear the
new framework defaults are commented out.
By mentioning `config.load_defaults` it hopefully clarifies that these
defaults should be similar to the onces defined by `load_defaults`.
Also reword "flip" to "uncomment" to make it clear you should uncomment
the config instead of setting `true` to `false`.
Fix a bug introduced by
3fe0ab52df
that raised an undefined method when trying to deep merge an array with
an empty config hash
It also adds a test to clarify config_for behaviour with root arrays: when there's
an env array and a shared array, it should only returns the env key (and not a concatenation)
Closes#42698
When passing an invalid index type to a generator, the index is silently
ignored. For example when misspelling the index:
bin/rails g model post title:string:indxe
Instead of silently ignoring the invalid index, the generator should
raise an error.
This continues the work in d163fcd620
where we started raising errors if the attribute types are invalid.
All new 7.0 framework defaults don't have an extra linebreak between the
explanation and the actual config.
For consistency we should remove it for `hash_digest_class` as well.
As of Ruby 2.7 DidYouMean is included as a default gem, so there is no
need to check if DidYouMean is defined in the test suite. We still need
to check if the DidYouMean modules are defined in the actual code, as
someone might run Rails with DidYouMean disabled by using the
`--disable-did_you_mean` flag. This is ussually done for performance
reasons.
This commit also includes some of the changes made by Yuki in:
https://github.com/rails/rails/pull/39555
These changes include replacing Jaro with the more accurate
SpellChecker, and using DidYouMean::Correctable for simplere
corrections.
The DidYouMean::SpellChecker does have a treshold for corrections.
If there is not enough similarity it might not return a suggestion.
To stop the tests from failing some test data had to be changed.
For example, `non_existent` does not meet the treshold for `hello`, but
`ello` does:
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('non_existent')
=> []
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('ello')
=> ["hello"]
The treshold makes sense for spelling errors. But maybe we should add a
different SpellChecker that helps to get a suggestion even if there is
little overlap. For example for when a model only has 2 attributes
(title and body), it's helpful to get a suggestion for `name`
Co-Authored-By: Yuki Nishijima <yk.nishijima@gmail.com>
Breno Gazzola