This change would force a lot of existing applications and libraries
to update their tests.
We included it in the beta to collect feedback from the community and
we had some comments about how negative this change would be.
Developers that care about the typography of their error messages
can easily change it in their applications using the translation
files, so there is no need to inflict pain in the upgrade process
by changing the default in the framework.
Revert "Merge PR #45463"
This reverts commit 9f60cd8dc7, reversing
changes made to 35d574dbfd.
When [rails/rails#20868][] changed the `ActionController::Parameters`
ancestory from `HashWithIndifferentAccess` to `Object`, support for
`#deep_merge` and `#deep_merge!` were omitted.
This commit restores support by integrating with
[ActiveSupport::DeepMergeable](./activesupport/lib/active_support/deep_mergeable.rb).
[rails/rails#20868]: https://github.com/rails/rails/pull/20868
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
We were reviewing this test while doing some work around transaction
tracking and noticed that the comment here seemed to no longer be the case.
`materialize_transactions` doesn't actually dirty the transaction anymore, so
it shouldn't be required to stub this out. Indeed, the tests continue to pass
without this method stub.
Co-authored-by: Daniel Colson <composerinteralia@github.com>
Mysql automatically escapes quotes in generated check constraints expressions.
When Rails dumps the schema (into schema.rb) the generated schema also contains,
the quotes with duplicated escaping (\\\\').
To fix this, we remove the escaping, that MySQL provides from the fetched
expression.
This will avoid those connection leaking to other tests.
They cause problem because the fixtures loading will try to open
a transaction on all the active connections and since those connections
use a database pointing to a temp file that doesn't exist anymore
if any transaction try to start on them it will fail.
Fixes#49373.
As we (I and @yahonda) talked about the naming in person, naming unique
constraints as unique keys is very confusing to me.
All documents and descriptions says it's unique constraints, but naming
unique keys leads to misunderstanding it's a short-hand of unique
indexes.
Just naming it unique constraints is not misleading.
* Update description for filter_parameter_logging
* Update railties/lib/rails/generators/rails/app/templates/config/initializers/filter_parameter_logging.rb.tt
Thanks Rob!!. I did all this in the github ui and was a little out of sorts with the wrapping.
Co-authored-by: Rob Zolkos <rob@zolkos.com>
---------
Co-authored-by: Rob Zolkos <rob@zolkos.com>
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
- ## Context
While working on https://github.com/rails/rails/pull/44695, I
realised that Broadcasting was still a private API, although it’s
commonly used. Rafael mentioned that making it public would require
some refactor because of the original implementation which was hard
to understand and maintain.
### Changing how broadcasting works:
Broadcasting in a nutshell worked by “transforming” an existing
logger into a broadcasted one.
The logger would then be responsible to log and format its own
messages as well as passing the message along to other logger it
broadcasts to.
The problem with this approach was the following:
- Heavy use of metaprogramming.
- Accessing the loggers in the broadcast wasn’t possible.
Removing a logger from the broadcast either.
- More importantly, modifying the main logger (the one that broadcasts
logs to the others) wasn’t possible and the main source of
misunderstanding.
```ruby
logger = Logger.new(STDOUT)
stderr_logger = Logger.new(STDER))
logger.extend(AS::Logger.broadcast(stderr_logger))
logger.level = DEBUG # This modifies the level on all other loggers
logger.formatter = … # Modified the formatter on all other loggers
```
To keep the contract unchanged on what Rails.logger returns, the new
BroadcastLogger class implement duck typing with all methods
that has the vanilla Ruby Logger class.
It's a simple and boring PORO that keeps an array of all the loggers
that are part of the broadcast and iterate over whenever a log is
sent.
Now, users can access all loggers inside the broadcast and modify
them on the fly. They can also remove any logger from the broadcast
at any time.
```ruby
# Before
stdout_logger = Logger.new(STDOUT)
stderr_logger = Logger.new(STDER)
file_logger = Logger.new(“development.log”)
stdout_logger.extend(AS::Logger.broadcast(stderr_logger))
stdout_logger.extend(AS::Logger.broadcast(file_logger))
# After
broadcast = BroadcastLogger.new(stdout_logger, stderr_logger, file_logger)
```
I also think that now, it should be more clear for users that the
broadcast sole job is to pass everything to the whole loggers in
the broadcast. So there should be no surprise that all loggers in
the broadcast get their level modified when they call
`broadcast.level = DEBUG` .
It’s also easier to wrap your head around more complex setup such
as broadcasting logs to another broadcast:
`broadcast.broadcast_to(stdout_logger, other_broadcast)`
Fixes https://github.com/rails/rails/issues/48477
Using forms inside emails is not common, but it's possible, and it's also possible to share views between controllers and mailers. Currently if a controller sets a `default_form_builder` that's different from the global config, mailers that use the same views will not default to the same `FormBuilder`. To fix this, this PR adds a `default_form_builder` method for mailers that does the same thing as its controller sibling.
This is a follow-up to https://github.com/rails/rails/pull/45606
We were storing the file metadata in Blob and Attachment but we were not
actually uploading the files (into the file system for instance for disk
storage).
It was failing silently so I made it explicit what is accepted and what
is unexpected
### Why was this change necessary?
When creating models in tests, it's easier to pass a File or a Pathname
(from `file_fixture` for instance) to `Model.create` for instance
### How does it address the problem?
When attaching an attachable, we check if it's a File or a Pathname and
handle it appropriately.
The `concurrent` require was [added][1] previously because a
`Concurrent::Map` was added to hold all of the log levels by `Thread` id.
However, the `Map` was later [removed][2] by storing the log levels in the
`Thread` locals (and later in `IsolatedExecutionState`) instead. The new
implementation additionally removed the `cattr_accessor` (removing the
need to require the "attribute_accessors" core_ext) and also replaced
the [usage][3] of `Fiber` with `Thread` (so the require for `Fiber` is also no
longer necessary).
Since `Concurrent`, `Fiber`, and `cattr_accessor` are no longer used here, we
can remove the requires. Since `Logger` is used here (but was previously
required by `concurrent`), a require was added for it.
[1]: 629efb6057
[2]: 2379bc5d2a
[3]: 56ec504db6
Rafael Mendonça França