The PR #36860 changed ActionView's required version of
rails-html-sanitizer, but I missed that we needed to run bundle,
otherwise we end up with changes every time.
As demonstrated in the test added and in #36830 the code that prevents
writes wasn't thread safe. If one thread does a read, then another does
a write, and then another does a read the second read will cause the
first write to be unwriteable.
This change removes the instance variable and instead uses a
getter/setter on Thread.current[:prevent_writes] for the connection
handler to set whether writes are allowed.
Fixes#36830
Currently, the `perform_enqueued_jobs` helpers will also immediately
perform jobs that are scheduled via `set(wait:)` to run in the future.
This commit adds a new argument to `perform_enqueued_jobs` to make it
only run jobs scheduled at or before the passed in `Time`. This allows
testing the side effects of immediate job execution separate of jobs
delayed in the future.
Commit 52f0b050e2 replaces `white_list_sanitizer` with `safe_list_sanitizer`. This is a breaking change unless the installed version of `rails-html-sanitizer` is `>= 1.1.0`.
This commit updates the minimum version in `actionview/actionview.gemspec` to `1.1.0`.
Added the ability to initialize `thread_mattr_*` methods with default
values like so:
``` ruby
class MyClass
thread_attr_reader :foo, default: :foo
thread_attr_writer :bar, default: :bar
thread_attr_accessor: baz do
"baz"
end
end
```
This is consistent with the api exposed by `mattr_accessor`.
These calls to `content_type` were triggering the deprecation from
c631e8d011 in upgraded applications.
We can use `media_type` in all of these cases to avoid the deprecation.
Didn't like the complicated stuff that happened on credentials:edit. It
would append to .gitattributes multiple times. Though I see why it was
written that way.
I'm cutting off for now, but since this new flow would require each developer
to run --enable perhaps this should really be:
1. Developer enrolls Rails app by running `credentials:diff --enable`
2. credentials:edit checks .gitattributes for `diff=rails_credentials` and
if the current file is covered by that.
3. If so, set up the "rails_credentials" driver automatically.
Helpers is more for sharing between commands. Since `Diffing` is only
for credentials we should just keep it only for credentials.
Replaces "pretty" with diffing since the former is ambiguous, while
diffing captures what it does. `opt_in` seemed clunky so it's swapped
for the one-word enable.
```ruby
$ cd activerecord
$ bin/test test/cases/dirty_test.rb:494
... snip ...
DEPRECATED: Use assert_nil if expecting nil from /home/yahonda/git/rails/activerecord/test/cases/dirty_test.rb:494. This will fail in Minitest 6.
DEPRECATED: Use assert_nil if expecting nil from /home/yahonda/git/rails/activerecord/test/cases/dirty_test.rb:511. This will fail in Minitest 6.
.
Finished in 0.061593s, 16.2356 runs/s, 795.5428 assertions/s.
1 runs, 49 assertions, 0 failures, 0 errors, 0 skips
$
```
Refer seattlerb/minitest#666rails/rails#27712
At first this appeared to be a multi-db bug but after some invesitgation
it was clear that this can occur just by calling `establish_connection`
from ApplicationRecord.
After some investigation we found that this only occurred when using
fixtures. The console boots fine, the server runs fine, and the tests
even run fine if we used paralellization or eager loading in the tests.
I tracked the issue down to the line that calls
`self.connection_specification_name = name` in the SchemaMigration
changes for Rails 6.0. But how can this be? That is not that major of a
change? How could `connection_specification_name` be a problem?
First `connection_specification_name` caches the name of the connection
specificatio. Second, fixtures were incorrectly holding onto a reference
to that connection.
So when you went to run the tests the models wouldn't be connected and
when the fixtures tried to load the data it would choke on that
unconnected database.
The changes here move the connection into a lambda so we can call it
when we need it rather than blowing up before the model is connected.
Fixes#36743
Co-authored-by: Aaron Patterson <aaron.patterson@gmail.com>
Usually the application requires the entire active support at load time
but the configuration happens before it is loaded. For that reason we
need to require the core_ext that we want to use in this file.
Previously if an app attempts to do a write inside a read request it will be
impossilbe to switch back to writing to the primary. This PR adds an
argument to the `while_preventing_writes` so that we can make sure to
turn it off if we're doing a write on a primary.
Fixes#36830
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
eileencodes