| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
Because the deprecation message is not yet released.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Let's say you have a nested transaction and both records are saved.
Before the outer transaction closes, a rollback is performed. Previously
the record in the outer transaction would get marked as not persisted
but the inner transaction would get persisted.
```ruby
Post.transaction do
post_one.save # will get rolled back
Post.transaction(requires_new: true) do
post_two.save # incorrectly remains marked as persisted
end
raise ActiveRecord::Rollback
end
```
To fix this the PR changes transaction handling to have the child
transaction ask the parent how the records should be marked. When
there are child transactions, it will always be a SavpointTransaction
because the stack isn't empty. From there we pass the parent_transaction
to the child SavepointTransaction where we add the children to the parent
so the parent can mark the inner transaction as rolledback and thus mark
the record as not persisted.
`update_attributes_from_transaction_state` uses the `completed?` check to
correctly mark all the transactions as rolledback and the inner record as
not persisted.
```ruby
Post.transaction do
post_one.save # will get rolled back
Post.transaction(requires_new: true) do
post_two.save # with new behavior, correctly marked as not persisted
on rollback
end
raise ActiveRecord::Rollback
end
```
Fixes #29320
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`set_state` was directly setting the transaction state instance
variable. It's better to set the state via specific methods (`rollback!`
and `commit!` respectively.
While undocumented and untested, it's possible someone is using
`set_state` in their app or gem so I've added a deprecation notice to
it.
No where in the app do we use `nullify!` but I wanted to keep existing
behavior while replacing the method with a better pattern.
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |\
| | |
| | |
| | | |
Enforce frozen string in Rubocop
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
Make ActiveSupport frozen-string-literal friendly.
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
`test_middleware_caches` is sometimes failed since #29454.
The failure is due to schema statements are affected by query caching.
Bypassing query caching for schema statements to avoid the issue.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`test_cache_is_available_when_using_a_not_connected_connection` is
always failed if running only the test since #29609.
```
% ARCONN=mysql2 be ruby -w -Itest test/cases/query_cache_test.rb -n test_cache_is_available_when_using_a_not_connected_connection
Using mysql2
Run options: -n test_cache_is_available_when_using_a_not_connected_connection --seed 15043
F
Finished in 0.070519s, 14.1806 runs/s, 28.3612 assertions/s.
1) Failure:
QueryCacheTest#test_cache_is_available_when_using_a_not_connected_connection [test/cases/query_cache_test.rb:336]:
2 instead of 1 queries were executed.
Queries:
SELECT `tasks`.* FROM `tasks` WHERE `tasks`.`id` = ? LIMIT ?
SET NAMES utf8 COLLATE utf8_unicode_ci, @@SESSION.sql_mode = CONCAT(CONCAT(@@sql_mode, ',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'), @@SESSION.sql_auto_is_null = 0, @@SESSION.wait_timeout = 2147483.
Expected: 1
Actual: 2
1 runs, 2 assertions, 1 failures, 0 errors, 0 skips
```
This failure is due to `LogSubscriber` will use not connected
`ActiveRecord::Base.connection` even if `Task.connection` is connected.
I fixed to always pass `type_casted_binds` to log subscriber to avoid
the issue.
|
|\ \
| | |
| | | |
`Relation#locked?` should not build arel
|
| | |
| | |
| | |
| | |
| | | |
The delegation was needed since passing `relation` with
`relation.bound_attributes`. It should use `relation.arel` in that case.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Scalar values like arrays and hashes can't be inserted
directly into table. Previously, the way to determine if
the value is scalar was to try quoting it. If `quote` raised
with an error than the value has to be converted to YAML.
This flow is not very obvious. Ideally we could have
a `quotable?` method in the connection, but I think
that we can avoid begin/rescue block by simply checking
if the value is Array or Hash.
https://github.com/rails/rails/commit/aa31d21f5f4fc4d679e74a60f9df9706da7de373
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Improves the performance from O(n) to O(1).
Previously it would require 50 queries to
insert 50 fixtures. Now it takes only one query.
Disabled on sqlite which doesn't support multiple inserts.
|
|\ \
| |/
|/| |
Refactor #insert_fixtures to use Arel
|
| | |
|
|\ \
| |/
|/| |
Fix `create_table` with query from relation
|
| |
| |
| |
| |
| | |
If a relation has binds, `connection.to_sql(relation)` without binds
will generate invalid SQL. It should use `relation.to_sql` in that case.
|
|/
|
|
| |
Fixes #29460.
|
|
|
|
| |
This option was added in b9fa354. But it does not seem to work.
|
| |
|
|\
| |
| |
| |
| | |
Nerian/document_support_for_composite_primary_keys
Document support for composite primary keys
|
| | |
|
|\ \
| | |
| | | |
Both reference id and type should be `NOT NULL` if `null: false` is specified
|
| |/
| |
| |
| |
| |
| | |
This is a regression due to #28282.
Fixes #29136.
|
|/
|
|
| |
present.
|
|
|
|
|
| |
In this case, it's the method definition that's more at fault, rather
than the current caller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`supports_statement_cache?` was introduced in 3.1.0.beta1 (104d0b2) for
bind parameter substitution, but it is no longer used in 3.1.0.rc1
(73ff679). Originally it should respect `prepared_statements` rather
than `supports_statement_cache?` (fd39847).
One more thing, named `supports_statement_cache?` is pretty misreading.
We have `StatementCache` and `StatementPool`. However,
`supports_statement_cache?` doesn't mean `StatementCache`, but
`StatementPool` unlike its name.
https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/statement_cache.rb
https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/connection_adapters/statement_pool.rb
|
| |
|
|
|
|
|
|
|
|
|
| |
'lookup' is the noun. 'to look up' is the verb. Looked it up just to
be sure.
cf.
https://en.wiktionary.org/wiki/lookup
https://en.wiktionary.org/wiki/look_up
|
|
|
|
| |
Since 1a92ae83 all `indexes` methods are under the `SchemaStatements`.
|
|
|
|
|
|
|
| |
* Use keyword arguments in `IndexDefinition` to ease to ignore unused
options and to avoid to initialize incorrect empty value.
* Place it in `SchemaStatements` for consistency.
* And tiny tweaks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transactional-fixture using tests with racing threads and inter-thread
synchronisation inside transaction blocks will now deadlock... but
without this, they would just crash.
In 5.0, the threads didn't share a connection at all, so it would've
worked... but with the main thread inside the fixture transaction, they
wouldn't've been able to see each other.
So: as far as I can tell, the set of operations this "breaks" never had
a compelling use case. Meanwhile, it provides an increased level of
coherency to the operational feel of transactional fixtures.
If this does cause anyone problems, they're probably best off disabling
transactional fixtures on the affected tests, and managing transactions
themselves.
|
|
|
| |
`ActiveRecord::Base.establish_connection` accepts a single symbol argument to specify a named connection; a single string argument appears to be interpreted as a connection URI
|
| |
|
|
|
|
| |
Follow up of #27939.
|
|\
| |
| | |
Remove duplicated `columns` definition
|
| | |
|
|\ \
| |/
|/| |
Fix `select_all` with legacy `binds`
|
| |
| |
| |
| | |
Fixes #27923.
|
|\ \
| | |
| | | |
Extract `data_source_sql` to refactor data source statements
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Use `SchemaMigration.all_versions` instead of
`SchemaMigration.all.map(&:version)` to avoid to instantiate AR objects.
|
| | |
| | |
| | |
| | | |
Simply use `SchemaMigration.table_name` instead.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Related #25174.
`db:schema:load` doesn't work with subdirectories like previous
`db:migrate:status`. `Migrator.migration_files` should be used in
`assume_migrated_upto_version` to fix the issue.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sharing `options` causes some unexpected behavior. If `limit: 2` is
specified, this means that 2 bytes integer for a reference id column and
2 chars string for a reference type column. Another example, if
`unsigned: true` is specified, this means that unsigned integer for a
reference id column, but a invalid option for a reference type column.
So `options` should not be shared with a reference type column.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Follow up of #26266.
The default type of `primary_key` and `references` were changed to
`bigint` since #26266. But `create_join_table` column type is still
`integer`. It should respect `references` column type.
|