* Add encryption.add_to_filter_parameters to configuring.md
encryption.add_to_filter_paramters has been merged by https://github.com/rails/rails/pull/46453.
(This PR is a second try of https://github.com/rails/rails/pull/49364 )
* Update entry for encryption.add_to_filter_parameters
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
Fix: https://github.com/rails/rails/issues/49439
Because Postgres adapter types are connection dependent,
we can't lookup types without first connecting to the database.
Note, this really isn't good, ideally types should be stored in the
schema cache so that we don't have to extract types every time.
`ENV` values are strings, so `ENV["RAILS_MAX_THREADS"]` must be parsed
as an int.
Unfortunately, `MessagePack::Factory::Pool::MemberPool` does not expose
a method to check its member count, so the most we can assert is that
roundtripping works as expected.
Fixes#49446.
This reverts commit 54f30488e190eea5e923fe51914051df0e8c33f6.
Reason: THis isn't necessary. `TZInfo::DataSource.get` makes sure
the exception gets translated.
rails new --skip-aciton-cable now generates config/environments/development.rb
without Action Cable configurations.
Follows up PRs 22586 and 24169
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
It's possible since Rails 6 (3ea2857943dc294d7809930b4cc5b318b9c39577) to let the framework create Event objects, but the guides and docs weren't updated to lead with this example.
Manually instantiating an Event doesn't record CPU time and allocations, I've seen it more than once that people copy-pasting the example code get confused about these stats returning 0. The tests here show that - just like the apps I've worked on - the old pattern keeps getting copy-pasted.
- An oversight of #48615 is that it changes the `Rails.logger` to be
a broadcast logger after the app is booted. Anything referencing
`Rails.logger` during the boot process will get a simple logger and
ultimately resulting in logs not being broadcasted.
For example `ActionController::Base.logger.info("abc")` would
just output logs in the `development.log` file, not on STDOUT.
----
The only solution I could think of is to create a BroadcastLogger
earlier at boot, and add logger to that broadcast when needed (instead
of modiyfing the `Rails.logger` variable).
Ideally we should be able to checkout an Adapter instance without
triggering a connection to the server.
For some adapters like Trilogy that is the case today, but only if
you have a schema cache loaded, otherwise `check_version` will trigger
a query.
I think this check can be delayed to when we actually use the connection.
This was [added][1] when the default configuration was added for Rails
5.2, however the accessor itself has never been documented or used.
`protect_from_forgery: :exception` is added based on whether the
configuration is set on `config.action_controller` and not this value.
Since the accessor is undocumented and unused, this commit removes it.
[1]: 48cb8b3e7097e9a1cb45b2298f59b9179f0dbdee
Ref: https://github.com/rails/rails/pull/49378
As discussed with Matthew Draper, we have a bit of a chicken and egg
problem with the schema cache and the database version.
The database version is stored in the cache to avoid a query,
but the schema cache need to query the schema version in the database
to be revalidated.
So `check_version` depends on `schema_cache`, which depends on
`Migrator.current_version`, which depends on `configure_connection`
which depends on `check_version`.
But ultimately, we think storing the server version in the cache
is incorrect, because upgrading a DB server is orthogonal from
regenerating the schema cache.
So not persisting the version in cache is better. Instead we store
it in the pool config, so that we only check it once per process
and per database.
