The methods with tests added here is for the query methods that uses
`check_if_method_has_arguments!` in `ActiveRecord::QueryMethods`.
However, some of these query methods had no tests.
- Ensure that explicit method call `connected_to` with `prevent_writes: false`
turns off 'preventing writes' in the passed block.
- Ensure that after explicit call method call `connected_to` with `prevent_writes: false`
'preventing writes' is retained
Related to https://github.com/rails/rails/pull/37065
If a user is using the middleware for swapping database connections and
manually calling `connected_to` in a controller/model/etc without
calling `while_preventing_writes(false)` there is potential for a race
condition where writes will be blocked.
While the user could _just_ call `while_preventing_writes` in the same
place they call `connected_to` this would mean that all cases need to
call two methods.
This PR changes `connected_to` to call `while_preventing_writes`
directly. By default we'll assume you don't want to prevent writes, but
if called with `connected_to(role: :writing, prevent_writes: true)` or
from the middleware (which calls `connected_to` this way) the writes
will be blocked.
For replicas, apps should use readonly users to enforce not writing
rather than `while_preventing_writes` directly.
Should fix the remaining issues in
https://github.com/rails/rails/issues/36830
After forking, the connection handler will discard any connection pools that belongs to the parent process. However, it will continue to hold a reference to the connection pools of the parent process which is used for retrieval of the connection pool in the child process. Therefore, the `weakref_alive?` check in the connection pool reaper is insufficient since the connection pools of the parent process is never GCed.
This broke in 3e2e8ee where it switched to one reaper thread per
process. However, the implementation will only spawn the reaping thread
if the reaping frequency has not been seen. Since the reaping
frequencies are stored in a class instance variable, that variable is
copied when the process is forked. As such, a forked process will not
spawn a new reaping thread since the class instance variable would have
contain the reaping frequency that was seen in the parent process.
This commit tracks threads separately and checks that they both have
been spawned and are currently alive.
This adds a failing test to reaper_test.rb, based on the previous test
without forking. It also improves the test to return an failure instead
of hanging forever if the reaper is not started.
Co-authored-by: Guo Xiang Tan <tgx_world@hotmail.com>
This fixes a race condition in system tests where prepared
statements can be incorrectly parameterized when multiple
threads observe the mutation of the @prepared_statements
instance variable on the connection.
Fixes#36763
Since 2f8b397258b66581409b0e6537f98ea9b56e9f19, `ActiveRecord::Base` and
`ApplicationRecord` use the same default `connection_specification_name`
so that database connections configured on `ApplicationRecord` also
apply to `ActiveRecord::Base`.
However, when resolving the connection for `ApplicationRecord` we should
continue to fall back to `ActiveRecord::Base` when there's no connection
explicitly configured, so that setting `connection_specification_name`
on `ActiveRecord::Base` affects `ApplicationRecord` and its descendants
in this case as it did in previous versions.
Actually, `first` taking non-deterministic result is considered a bug to
me. But changing the behavior should not be happened in rc2.
I've restored the behavior for 6.0, and then will deprecate that in 6.1.
Fixes#36802.
c9e4c848 has one performance optimization for `aggregate_alias` to early
returning by `aggregate_alias.match?(/\A\w+\z/)`, but it is caused a
regression that failing deduplication for non word chars #36867.
I've quited the optimization and add a test to prevent a future
regression.
Fixes#36867.
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
```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
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>
In our app at work we had a faked config like this:
```
{ "foo" => :bar, "bar" => { "adapter" => "memory" } }
```
This config is invalid. You can't say for foo env just have a symbol,
nor would this work if you had fa foo env with just a string. A
configuration must be a url or an adapter or a database. Otherwise it's
invalid and we can't parse it.
When this was just yaml turned into hashes you could get away with
passing whatever. It wouldn't work but it wouldn't blow up either.
Now that we're using objects we were returning `nil` for these but that
just means we either blow up on `for_current_env` or compact the
`nil`'s.
I think it's a better user experience to not build the configs and raise
an appropriate error.
This is also an invalid config because if you do pass a string here it
should be a URL.
```
{ "foo" => "bar", "bar" => { "adapter" => "memory" } }
```
#36805 have one possible regression that failing deduplication if
`joins_values` have complex order (e.g. `joins_values = [join_node_a,
:comments, :tags, join_node_a]`).
This fixes the deduplication to take it in the first phase before
grouping.
In case of a polymorphic association there's no automatic inverse_of to assign the
inverse record. So to get the record there needs to be a query executed,
however, if the query fires within the transaction that's trying to create
the associated record, no record can be found. And worse, the nil result is cached
on the association so after the transaction commits the record can't be found.
That's what happens if touch is enabled on a polymorphic has_one association.
Consider a Comment with a commentable association that needs to be touched.
For `Comment.create(commentable: Post.new)`, the existing code essentially
does `commentable.send(:comment)` within the create transaction for the comment
and thus not finding the comment.
Now we're purposefully clearing the cache in case we've tried accessing
the association within the transaction and found no object.
Before:
```
kaspth-imac 2.6.3 ~/code/rails/activerecord master *= ARCONN=postgresql bin/test test/cases/associations/has_one_associations_test.rb -n /commit/
Using postgresql
Run options: -n /commit/ --seed 46022
D, [2019-07-19T03:30:37.864537 #96022] DEBUG -- : Chef Load (0.2ms) SELECT "chefs".* FROM "chefs" WHERE "chefs"."employable_id" = $1 AND "chefs"."employable_type" = $2 LIMIT $3 [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"], ["LIMIT", 1]]
D, [2019-07-19T03:30:37.865013 #96022] DEBUG -- : Chef Create (0.2ms) INSERT INTO "chefs" ("employable_id", "employable_type") VALUES ($1, $2) RETURNING "id" [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"]]
D, [2019-07-19T03:30:37.865201 #96022] DEBUG -- : TRANSACTION (0.1ms) RELEASE SAVEPOINT active_record_1
D, [2019-07-19T03:30:37.874136 #96022] DEBUG -- : TRANSACTION (0.1ms) ROLLBACK
D, [2019-07-19T03:30:37.874323 #96022] DEBUG -- : TRANSACTION (0.1ms) ROLLBACK
F
Failure:
HasOneAssociationsTest#test_polymorphic_has_one_with_touch_option_on_create_wont_cache_assocation_so_fetching_after_transaction_commit_works [/Users/kaspth/code/rails/activerecord/test/cases/associations/has_one_associations_test.rb:716]:
--- expected
+++ actual
@@ -1 +1 @@
-#<Chef id: 1, employable_id: 1, employable_type: "DrinkDesignerWithPolymorphicTouchChef", department_id: nil, employable_list_type: nil, employable_list_id: nil>
+nil
```
After:
```
kaspth-imac 2.6.3 ~/code/rails/activerecord master *= ARCONN=postgresql bin/test test/cases/associations/has_one_associations_test.rb -n /commit/
Using postgresql
Run options: -n /commit/ --seed 46022
D, [2019-07-19T03:30:22.479387 #95973] DEBUG -- : Chef Create (0.3ms) INSERT INTO "chefs" ("employable_id", "employable_type") VALUES ($1, $2) RETURNING "id" [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"]]
D, [2019-07-19T03:30:22.479574 #95973] DEBUG -- : TRANSACTION (0.1ms) RELEASE SAVEPOINT active_record_1
D, [2019-07-19T03:30:22.482051 #95973] DEBUG -- : Chef Load (0.1ms) SELECT "chefs".* FROM "chefs" WHERE "chefs"."employable_id" = $1 AND "chefs"."employable_type" = $2 LIMIT $3 [["employable_id", 1], ["employable_type", "DrinkDesignerWithPolymorphicTouchChef"], ["LIMIT", 1]]
D, [2019-07-19T03:30:22.482317 #95973] DEBUG -- : TRANSACTION (0.1ms) ROLLBACK
D, [2019-07-19T03:30:22.482437 #95973] DEBUG -- : TRANSACTION (0.1ms) ROLLBACK
.
Finished in 0.088498s, 11.2997 runs/s, 22.5994 assertions/s.
1 runs, 2 assertions, 0 failures, 0 errors, 0 skips
```
Notice the select now fires after the commit.
To suppress the following warnings in tests.
```
~/rails/activerecord/lib/active_record/scoping/named.rb:190: warning: method redefined; discarding old not_sent
~/rails/activerecord/lib/active_record/scoping/named.rb:190: warning: previous definition of not_sent was here
```
Currently, string joins are always applied as last joins part, and Arel
join nodes are always applied as leading joins part (since #36304), it
makes people struggled to preserve user supplied joins order.
To mitigate this problem, preserve the order of string joins and Arel
join nodes either before or after of association joins.
Fixes#36761.
Fixes#34328.
Fixes#24281.
Fixes#12953.
Previously it was the responsibility of the database tasks to translate
the invalid statement from creating a duplicate database into an
ActiveRecord::Tasks::DatabaseAlreadyExists error.
It's actually easier for us to do this detection inside of the adapter,
where we already do a case statement on the return code to translate the
error.
This commit introduces ActiveRecord::DatabaseAlreadyExists, a subclass
of StatementInvalid, and updates both AbstractMysqlAdapter and
PostgresqlAdapter to return this more specific exception in that case.
Because this is a subclass of the old exception, StatementInvalid, it
should be backwards compatible with any code expecting that from
create_database.
This works for both create_database and exectute("CREATE DATABASE")
Previously matches_regex was only availble on PostgreSql, this will enable it for MySql
Usage example:
users = User.arel_table;
users = User.arel_table; User.where(users[:email].matches_regexp('(.*)\@gmail.com'))
Update activerecord/test/cases/arel/visitors/mysql_test.rb
Co-Authored-By: Ryuta Kamizono <kamipo@gmail.com>
Allow specifying what fixtures can be ignored by setting
`ignore` in fixtures YAML file:
# users.yml
_fixture:
ignore:
- base
base: &base
admin: false
introduction: "This is a default description"
admin:
<<: *base
admin: true
visitor:
<<: *base
In the above example, "base" fixture will be ignored when creating
users fixture. This is helpful when you want to inherit attributes
and it makes your fixtures more "DRY".
