The default was changed in c2b96e3 but this test was not updated. Since
the assertion would pass even if the initializer failed, it needs to be
changed to something else.
In an effort to find all the internal callers of `connection_handler` I
decided to remove any uses that are either:
1) Unnecessary - we can call what we need on Base or elsewhere without
going through the handler
2) Incorrect - there's a better way call the same thing. For exmaple
avoiding calling the ivar, and instead calling `send` on an existing
method.
Doing this will inform us what cases the connection handler is required
and how we can expand Base to provide everything an application or gem
could need without going through the handler. Reducing calls makes it
easier to replace or refactor in the future.
Fix: https://github.com/rails/rails/issues/45585
There's no benefit in serializing it as HWIA, it requires
to allow that type for YAML safe_load and takes more space.
We can cast it back to a regular hash before serialization.
It turns out that buildkite CI was running with mysql 8 and that means
we weren't testing the behavior of mysql 5.7. This fixes a failing test
in main due to the difference in error message.
CTE's are not supported for MySQL versions below 8.0, so these tests
were failing locally for me on MySQL 5.7. While 5.7 is quite old, it's
still supported and used by many major Rails applications and we need a
check for support in our tests.
In addition to this PR I'll need to get a buildkite build running for
5.7. This wasn't caught earlier because our buildkite upgraded to 8.0.
respond_to? is inherently slow, and the YAML class won't change whether
it does or does not respond to unsafe_load, so just check it once
during file load, and define methods accordingly.
This isn't a name to role mapping, it's a role to shard mapping. The
pool manager doesn't know it's name (only the connection handler does)
so it makes more sense to rename this ivar. Normally I wouldn't bother
since this is internal but since I'm doing a large refactor which
involves a lot of renaming, might as well get them all right.
In Psych >= 4.0.0, load defaults to safe_load. This commit
makes the ActiveRecord::Coders::YAMLColum class use Psych safe_load
as the Rails default.
This default is configurable via ActiveRecord.use_yaml_unsafe_load
We conditionally fallback to the correct unsafe load if use_yaml_unsafe_load
is set to true. unsafe_load was introduced in Psych 4.0.0
The list of safe_load permitted classes is configurable via
ActiveRecord.yaml_column_permitted_classes
[CVE-2022-32224]
This commit adds support for in-app custom credentials templates. When
a credentials file does not exist, `rails credentials:edit` will now try
to use `lib/templates/rails/credentials/credentials.yml.tt` to generate
the credentials file, before falling back to the default template.
This allows e.g. an open-source Rails app (which would not include
encrypted credentials files in its repo) to include a credentials
template, so that users who install the app will get a custom pre-filled
credentials file when they run `rails credentials:edit`.
Currently, when `config/credentials.yml.enc` is generated by
`CredentialsGenerator`, it includes a `secret_key_base` for convenience.
However, because `config/credentials/#{environment}.yml.enc` files are
generated by a different generator (`EncryptedFileGenerator`), they do
not include a `secret_key_base`.
This commit revises `CredentialsGenerator` to be more generator-like,
and changes `rails credentials:edit` to use it for generating both
`config/credentials.yml.enc` and `config/credentials/#{environment}.yml.enc`
files, thereby always including a `secret_key_base`.
Looking at connection management we were using `spec_name`,
`spec`, `owner_name`, `owner` and `connection_specification_name` to all mean
the "string representation of the name we use to lookup the connection".
In most applications this is the string representation of the class that
established the connection. In some rarer cases this is represented by
either passing a string to `owner_name` on `establish_connection` or
passing a config as a symbol which gets turned into an `owner_name`.
This behavior is undocumented and legacy, in most cases no longer
necessary. However I know that it is still in use so I'm going to slowly
work on replacing it so the behavior is less confusing.
For now this PR simply renames all the interal words to mean "string
that established the connection" to `connection_name`. In my next PR
I'll address the public APIs around `connection_specification_name` on
`Base` and `owner_name` on `ConnectionHandler`.
Note that the instrumentation in `establish_connection` is private
(denoted by the !), so it is safe to change without warning. Everything
else is internal naming or part of a private API.
https://github.com/rails/rails/pull/41395 added support for the `timestamptz` type on the Postgres adapter.
As we found [here](https://github.com/rails/rails/pull/41084#issuecomment-1056430921) this causes issues because in some scenarios the new type is not considered a time zone aware attribute, meaning values of this type in the DB are presented as a `Time`, not an `ActiveSupport::TimeWithZone`.
This PR fixes that by ensuring that `timestamptz` is always a time zone aware type, for Postgres users.
The Active Record Validations guide use `Person < ApplicationRecord`
in all examples. When reading about Custom Validators, one of the
examples had a different configuration. By using the same example
everywhere, this change helps the user save time and feel more confident
using the feature.
