Followup to 88fe76e69328d38942130e16fb65f4aa1b5d1a6b.
These are new in RuboCop 0.80.0, and enforce a style we already prefer
for performance reasons (see df81f2e5f5df46c9c1db27530bbd301b6e23c4a7).
Add `#strict_loading` to any record to prevent lazy loading of associations.
`strict_loading` will cascade down from the parent record to all the
associations to help you catch any places where you may want to use
`preload` instead of lazy loading. This is useful for preventing N+1's.
Co-authored-by: Aaron Patterson <aaron.patterson@gmail.com>
Before df186bd16f0d4a798e626297277fc6b490c1419e, `assign_attributes` and
`attributes=` were both defined in Active Model and both made a copy of
their argument. Now `assign_attributes` is overridden in Active Record
and the copy happens there instead, but `attributes=` isn't overridden.
This meant that assigning nested or multi-parameters via `attributes=`
would mutate the argument, which the copying was meant to prevent.
This issue is caused due to association queries uses newly created fresh
onetime predicate builder, it doesn't realize registered predicate
handler. To fix the issue, dup the predicate builder for the klass
instead of newly creating.
Fixes#38239.
Hopefully third time's a charm.
Originally, the schema cache initializer railtie was loading
the 'schema_cache.yml' file by hard-coding the path.
Since it's possible to override the schema cache path either by
providing an ENV variable, or by adding a configuration entry to
the database.yml config file, this means that we could potentially
end up not loading a cache that is configured to use a non-default
file.
The first attempt at fixing this (#38348) assumed that the
db config must contain a spec named 'primary'. This is not the case.
A second attempt at fixing this (#38383) bailed if no db config
was found.
This however, means that for an app without a db config named
'primary', we would not be attempting to load a schema cache
at all, even if they were using the default schema cache path.
Instead of bailing, here we go get the filename, passing a 'nil'
for the schema_cache_path, which will fall back to the default
path.
In Postgres, OIDs are *unsigned* 4 byte integers. Postgres allows
casting oids to integers so that you can have access to more operators;
however, doing this could lead to some issues if the oids are very large
as they might around to the negative number range.
From the Postgres docs:
> The oid type itself has few operations beyond comparison. It can be
> cast to integer, however, and then manipulated using the standard
> integer operators. (Beware of possible signed-versus-unsigned
> confusion if you do this.)
In most real-world databases this is never going to be a problem. In
order to reach the overflow, you have to have 2,147,483,648 objects in
your database (not rows, but relations, types, views, etc.). In extreme
cases though it is possible to reach that number and encounter some
buggy behavior.
See: https://www.postgresql.org/docs/12/datatype-oid.html
Rails has a number of places where a YAML configuration file is read,
then ERB is evaluated and finally the YAML is parsed.
This consolidates that into one common class.
Co-authored-by: Kasper Timm Hansen <kaspth@gmail.com>
- When a user passes `updated_at` to `upsert_all`, the given value is used.
- When a user omits `updated_at`, `upsert_all` touches the timestamp if (but only if) any upserted values differ.
Preserve Rails' ability to generate intelligent cache keys for ActiveRecord when using `upsert_all` frequently to sync imported data.
indexes in a table.
Currently the pg_class catalog is filtered out to retrieve the indexes in a
table by its relkind value. Which in versions lower than 11 of PostgreSQL
is always `i` (lower case). But since version 11, PostgreSQL
supports partitioned indexes referenced with a relkind value of `I`
(upper case). This makes any feature within the current code base to exclude those
partitioned indexes.
The solution proposed is to make use of the `IN` clause to filter those
relkind values of `i` and/or `I` when retrieving a table indexes.
It's been 6 years since [the original](https://github.com/rails/rails/pull/13584), so we're overdue for a sequel.
The correct word is "cannot", one word, not "can not", two words.
The schema cache defaults to loading the 'primary' database config.
However, if an app doesn't have a db config with a spec name of
'primary' the filename lookup will blow up.
This adds a fallback for this case.
This PR adds support for `if_exists` on `remove_column` and
`if_not_exists` on `add_column` to support silently ignoring migrations
if the remove tries to remove a non-existent column or an add tries to
add an already existing column.
We (GitHub) have custom monkey-patched support for these features and
would like to upstream this behavior.
This matches the same behavior that is supported for `create_table` and
`drop_table`. The behavior for sqlite is different from mysql/postgres
and sqlite for remove column and that is reflected in the tests.
The initializer that loads the default schema cache on the default
connection doesn't account for the case where an app overrides the
default filename either via ENV["SCHEMA_PATH"], or via the
:schema_cache_path defined in the db config.
Note that as discussed in #34449 this initializer doesn't work for
applications using multiple databases, and this change doesn't fix that.
