If you had a foreign key set and then decided to add `on_delete:
:cascade` later in another migration that migration would run but
wouldn't refresh the schema dump.
The reason for this was because `create_table_info` caches the statement
and sets it to be the same as the original declaration for the foreign
key (without the `on_delete: :cascade`.
PR #25307 ended up fixing this bug because it removes the check for
`create_table_info` and relies on reading from `information_schema`. The
fix however was intended to patch another bug. The reason this fixes the
issue is we're no longer parsing the regex from the cached
`create_table_info`.
This regression test is to ensure that the issue does not return if we
for some reason go back to using `create_table_info` to set the foreign
keys.
This method appears to have been partially used in connection pool
caching, but it was introduced without much reasoning or any tests. One
edge case test was added later on, but it was focused on implementation
details. This method is no longer used outside of tests, and as such is
removed.
This reverts commit 7ea502ae141fc26b736c7a73bdf7a676b1f9fc87, per
internal discussion with @sgrif -- this is documenting the
implementation of a class that isn't intended to be public API.
Currently `Type::Date#serialize` does not cast a value to a date object.
It should be cast to a date object for finding by date column correctly
working.
Fixes#25354.
`FinderMethods#exists?` should return a boolean rather than raising an
exception.
`UniquenessValidator#build_relation` catches a `RangeError` because it
includes type casting due to a string value truncation. But a string
value truncation was removed at #23523 then type casting in
`build_relation` is no longer necessary. aa06231 removes type casting in
`build_relation` then a `RangeError` moves to `relation.exists?`.
This change will remove the catching a `RangeError`.
Before we enable query caching we check if the connection is
connected. Before this fix we were always checking against the main
connection, and not the model connection.
We're going to be experimenting with a new bot for them. This will not
cause anything to start affecting new PRs yet, but it will have data
sent to them so they can do "dry run" stuff on their end.
The rubocop file is based on our documented style guide. I've only
included rules which are either already consistently applied throughout
the entire codebase, or where added lines should be following the
guideline regardless of the surrounding code (such as hash syntax)
`construct_relation_for_association_calculations` pass a string value to
`construct_join_dependency` when setting a string value in `from`.
It should not pass a string value, but always `joins_values`.
Related #14834, #19452.
Fixes#24193.
Previously model file was generated first, which resulted in
inheriting from `ActiveRecord::Base`, but since application_record.rb
is generated as well, it should already be used.
We were declaring in a few tests, which depending of
the order load will cause an error, as the super class could change.
see ac1c4e141b (commitcomment-17731383)
