This change allows for a connection to be swapped on role or shard for a
class. Previously calling `connected_to` would swap all the connections
to a particular role or shard. Granular connection swapping is useful
for swapping one connection to reading while leaving all other
connection classes on writing.
The public methods on connection handler have been updated to behave the
same as they did previously on the different handlers. The difference
however is instead of calling
`ActiveRecord::Base.connection_handlers[:reading].clear_all_connections!`
you now call
`ActiveRecord::Base.connection_handler.clear_all_connections!` which
will clear based on current role set by a `connected_to` block. Outside
the context of a `connected_to` block, `clear_all_connections!` can take
an optional parameter to clear specific connections by role.
The major changes in this PR are:
* We introduced a `legacy_connection_handling` configuration option that
is set to true by default. It will be set to `false` for all new
applications.
* In the new connection handling there will be one only connection
handler. Previously there was a connection handler for each role. Now
the role is stored in the `PoolManager`. In order to maintain backwards
compatibility we introduced a `LegacyPoolManager` to avoid duplicate
conditionals. See diagram in PR body for changes to connection
management.
* `connected_to` will now use a stacked concurrent map to keep track of
the connection for each class. For each opened block the `class`,
`role`, and `shard` will be added to the stack, when the block is exited
the `class`, `role`, `shard` array will be removed from the stack.
* With these changes `ActiveRecord::Base.connected_to` will remain
global. If called all connections in the block will use the `role` and
`shard` that was switched to. If called with a parent class like
`AnimalsRecord.connected_to` only models under `AnimalsRecord` will be
switched and everything else will remain the same.
Examples:
Given an application we have a `User` model that inherits from
`ApplicationRecord` and a `Dog` model that inherits from
`AnimalsRecord`. `AnimalsRecord` and `ApplicationRecord` have writing
and reading connections as well as shard `default`, `one`, and `two`.
```ruby
ActiveRecord::Base.connected_to(role: :reading) do
User.first # reads from default replica
Dog.first # reads from default replica
AnimalsRecord.connected_to(role: :writing, shard: :one) do
User.first # reads from default replica
Dog.first # reads from shard one primary
end
User.first # reads from default replica
Dog.first # reads from default replica
ApplicationRecord.connected_to(role: :writing, shard: :two) do
User.first # reads from shard two primary
Dog.first # reads from default replica
end
end
```
Things this PR does not solve:
* Currently there is no API for swapping more than one but not all
connections. Apps with many primaries may want to swap 3 but not all 10
connections. We plan to build an API for that in a followup PR.
* The middleware remains the same and is using the global switching
methods. Therefore at this time to use this new feature applications
must manually switch connections. We will also address this in a
followup PR.
* The `schema_cache` is currently on the `PoolConfig`. We plan on trying
to move this up to the `PoolManager` or elsewhere later on so each
`PoolConfig` doesn't need to hold a reference to the `schema_cache`.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
* Refactor railsrc file location to be xdg compliant
The XDG Base Directory Specification (which is currently used by
FOSS projects such as Git, Tmux, Pry, Rspec) provides a default
location for various file formats, including config/rc files.
This comment refactors app_generator.rb to load railsrc from
XDG_CONFIG_HOME if both XDG_CONFIG_HOME is set and rails/railrc
exists within the XDG_CONFIG_HOME location.
To maintain backwards compatibility it defaults back to ~/.railsrc
if either XDG_CONFIG_HOME is not set or there is no rails/railsrc.
* Refactor default_rc_file based on jonathanhefner PR feedback
* Update generators/rails/app/USAGE to explain railsrc XDG compliance
* Refactor default_rc_file based on sinsoku PR feedback
* Add test for ARGVScrubber.default_rc_file method
fileutils is required because tmpdir does not allow you to create a new
temp directory with a set title 'inside' another temporary directory, a
file is created for railsrc because tempfile creates a custom and unique
name preventing the specification of a file called 'railsrc'
Currently this test is failing because the ARGVScrubber class seems to
be loading directly from the gem (which still has the previous code)
rather than from the file itself. (loading the code in a pry session
and using show-method ARGVScrubber.default_rc_file reveals it is coming
from
gems/railties-6.0.3.3/lib/rails/generators/rails/app/app_generator.rb:536
instead of
railties/lib/rails/generators/rails/app/app_generator.rb
* Switch to double quote strings
* Add file deletion for argv_scrubber test
* Refactor test_xdg_config_no_custom_rc with jonathanhefner feedback
* Add Changelog for railsrc xdg-specification compliance
* Apply backtick and whitespace refactoring suggestsions from jonathanhefner
* Apply jonathanhefner suggested Changelog refactoring
[Rafael Mendonça França + Nick Wolf + Jonathan Hefner]
`Minitest.plugin_rails_init` sets `Minitest.backtrace_filter` to
`Rails.backtrace_cleaner` right before tests are run, overwriting the
value set in test_helper.rb.
`Rails.backtrace_cleaner` silences backtrace lines that do not start
with `Rails.root` followed by e.g. "lib/" or "test/". Thus when
`Rails.root` is a subdirectory of the project directory -- for example,
when testing a plugin that has a dummy app -- all lines of the backtrace
are silenced.
This commit adds a fallback such that when all backtrace lines are
silenced, the original `Minitest.backtrace_filter` is used instead.
Additionally, this commit refactors and expands existing test coverage.
Each stacked operation is a Proc object instead of operation name since fedde239dcee256b417dc9bcfe5fef603bf0d952,
and so we can now simply inline the target method for each operation
Permit applications to hack in custom DB config for ASt models until ASt has first-class multi-DB support:
ActiveSupport.on_load(:active_storage_record) do
connects_to reading: :active_storage_replica, writing: :active_storage_primary
end
rebase
Sometimes cascading association deletions can cause timeouts due to
an IO issue. Perhaps a model has associations that are destroyed on
deletion which in turn trigger other deletions and this can continue
down a complex tree. Along this tree you may also hit other IO
operations. Such deep deletions can lead to server timeouts while
awaiting completion and really the user may not notice all the
changes on their side immediately making them wait unnecesarially or
worse causing a timeout during the operation.
We now allow associations supporting the `dependent:` key to take `:destroy_async`,
which schedules a background job to destroy associations.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Co-authored-by: Cory Gwin @gwincr11 <gwincr11@github.com>
Right now it's already possible to set a digest class manually, but this
is not through a publicly supported and approved API. With these
configuration options, it is possible to configure a digest class to use
for digests inside Rails.
The reason for this is that it allows configuring other classes in
certain conditions like running in FIPS mode. FIPS disallows MD5 and
discourages SHA1. Even though this isn't used in Rails for security
related things, using newer hash algorithms means not having to explain
it to auditors which always makes life easier.
That's not the only reason though. If today Ruby is built and running
for example in an Ubuntu 18.04 FIPS approved environment, the default
Digest classes break, see https://bugs.ruby-lang.org/issues/13681 as
well.
By allowing a class to be configured, the following can be used so that
things work properly (using the new API proposed here):
```
Rails.application.config.active_support.hash_digest_class = OpenSSL::Digest::SHA256
```
This would then use the OpenSSL certified FIPS implementation as well.
.gitattributes files are a useful way to mark certain metadata about paths in a git repository (https://git-scm.com/docs/gitattributes). This can include all kinds of information, but one of the more useful ones is that linguist (https://github.com/github/linguist, the tool that powers the language statistics/diff view of GitHub) respects certain attributes. For example:
* `linguist-vendored` paths will not be counted toward the language statistics
* `linguist-generated` paths will not have their diff shown by default
These little niceties can be really helpful over time, so we should add it to the default app generator.
I recently learned that Rails logs at the :debug level (not the :info
level) by default in production environments. This is a surprising
behaviour, as other popular frameworks do not log at this level
by default. It would not be surprising if a developer accidentally
logged personally identifiable information (PII) in a production
environment due to this behaviour.
I noticed that [in 2014](https://github.com/rails/rails/pull/16622), the
Rails project made an intentional decision to set the default log level
to :debug. However, the landscape around logging PII has changed since
then with the introduction of legislation like GDPR, so I thought it
prudent to reopen this discussion.
Follow-up to #40143.
Rails Rake tasks are loaded for each new `Rake::Application` instance
via `Rails.application.load_tasks`. However, under the hood,
`Rails.application.load_tasks` used `require` instead of `load`, which
caused Rails tasks to be loaded for only the first `Rake::Application`
instance.
This commit changes the relevant `require` to `load`.
Fixes#40184.
The handling for single database applications has always set a schema.rb
or structure.sql files for loading the database schema. When we first
implemented multiple database support we intended to keep this for the
original, default database. Afterall Rails _has_ to connect to something
on boot. In development only one connection is connected on boot since
we don't eager load the app.
Originally we had thought that all applications should be required to
add a `primary` entry in the database configurations file. However,
this hasn't worked in practice and we have some code now that does not
assume there's a primary. The schema dumping/loading code however,
still assumed there was a "primary" in the configurations file.
We want the "default" database in any application to use the original
files even when converted to a multiple database application as this
reduces the need to make changes when implementing this functionality on
an existing application.
The changes here update Rails to ensure that we treat either "primary"
or the first database configuration for an environment as "default".
If there is a "primary" that will be used as the default configuration.
If there is no primary the configuration that is first for an
environment will be used as the default. For schema dump/load this means
that the default configuration (primary or first) will use `schema.rb`
as the filename and other configurations will use
`[CONFIGURATION_NAME]_schema.rb`.
This should also help us finish the pull request to infer migrations
paths since now we can say the first configuration is the default. This
is a natural assumption for application developers.
Followup to #39536
