| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Rollback parent transaction when children fails to update
Rails supports autosave associations on the owner of a `has_many`
relationship. In certain situation, if the children of the association
fail to save, the parent is not rolled back.
```ruby
class Employee < ActiveRecord::Base
end
class Company < ActiveRecord::Base
has_many(:employees)
end
company = Company.new
employee = company.employees.new
company.save
```
In the previous example, if the Employee failed to save, the Company
will not be rolled back. It will remain in the database with no
associated Employee.
I expect the `company.save` call to be atomic, and either create all or
none of the records.
The persistance of the Company already starts a transaction that nests
it's children. However, it didn't track the success or failure of it's
children in this very situation, and the outermost transaction is not
rolled back.
This PR makes the change to track the success of the child insertion and
rollback the parent if any of the children fail.
* Change the test to reflect what we expect
Once #32862 is merged, rolling back a record will rollback it's state to match
the state before the database changes were applied
* Use only the public API to express the tests
* Refactor to avoid reassigning saved for nested reflections
[Guillaume Malette + Rafael Mendonça França]
|
|\
| |
| | |
Disable foreign keys during `alter_table` for sqlite3 adapter
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unlike other databases, changing SQLite3 table definitions need to create a temporary table.
While changing table operations, the original table needs dropped which caused
`SQLite3::ConstraintException: FOREIGN KEY constraint failed` if the table is referenced by foreign keys.
This pull request disables foreign keys by `disable_referential_integrity`.
Also `disable_referential_integrity` method needs to execute `defer_foreign_keys = ON`
to defer re-enabling foreign keys until the transaction is committed.
https://www.sqlite.org/pragma.html#pragma_defer_foreign_keys
Fixes #31988
- This `defer_foreign_keys = ON` has been supported since SQLite 3.8.0
https://www.sqlite.org/releaselog/3_8_0.html and Rails 6 requires SQLite 3.8 #32923 now
- <Models>.reset_column_information added to address `ActiveModel::UnknownAttributeError`
```
Error:
ActiveRecord::Migration::ForeignKeyChangeColumnTest#test_change_column_of_parent_table:
ActiveModel::UnknownAttributeError: unknown attribute 'name' for ActiveRecord::Migration::ForeignKeyChangeColumnTest::Post.
```
|
|/ |
|
|\
| |
| | |
Bump minimum SQLite version to 3.8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These OS versions have SQLite 3.8 or higher by default.
- macOS 10.10 (Yosemite) or higher
- Ubuntu 14.04 LTS or higher
Raising the minimum version of SQLite 3.8 introduces these changes:
- All of bundled adapters support `supports_multi_insert?`
- SQLite 3.8 always satisifies `supports_foreign_keys_in_create?` and `supports_partial_index?`
- sqlite adapter can support `alter_table` method for foreign key referenced tables by #32865
- Deprecated `supports_multi_insert?` method
|
|/
|
|
|
| |
To prevent redundant `to_s` like https://github.com/rails/rails/pull/32923#discussion_r189460008
automatically in the future.
|
|
|
|
| |
So do not expose `PostgreSQLTypeMetadata` in the doc too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a real (non-savepoint) transaction has committed or rolled back,
the original persistence-related state for all records modified in that
transaction is discarded or restored, respectively.
When the model has transactional callbacks, this happens synchronously
in the `committed!` or `rolled_back!` methods; otherwise, it happens
lazily the next time the record's persistence-related state is accessed.
The synchronous code path always finalizes the state of the record, but
the lazy code path only pops one "level" from the transaction counter,
assuming it will always reach zero immediately after a real transaction.
As the test cases included here demonstrate, that isn't always the case.
By using the same logic as the synchronous code path, we ensure that the
record's state is always updated after a real transaction has finished.
|
|\
| |
| | |
Fix user_input_in_time_zone to coerce non valid string into nil
|
| |
| |
| |
| | |
Before it was coercing an invalid string into "2000-01-01 00:00:00".
|
|/
|
|
|
| |
Originally `SingularAssociation#replace` abstract method is private, and
doesn't intend to be called directly.
|
|
|
|
| |
Follow up of #19171 and #26825.
|
|
|
|
|
|
| |
After #449 was merged math can be done on these
nodes, adding a test file to unit test all the
math operators.
|
|\
| |
| | |
Add available transformations to docs
|
| |
| |
| |
| | |
`foreign_key`, `json` and `virtual` are also available.
|
| |
| |
| |
| | |
Follow up of #32605.
|
|\ \
| | |
| | | |
Remove ActiveRecord::Transactions#rollback_active_record_state!
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`rollback_active_record_state!` was removed from `save!` but not `save`
in da840d13da865331297d5287391231b1ed39721b. I believe that leaving it
in `save` was a mistake, since that commit was intended to move the
rollback logic from the `save`/`save!` call to the transaction stack.
As of 67d8bb963d5d51fc644d6b1ca20164efb4cee6d7 the record's original
state is lazily restored the first time it's accessed after the
transaction, instead of when a rollback occurs. This means that the call
to `restore_transaction_record_state` here has no effect: the record's
transaction level is incremented twice (in rollback_active_record_state!
and `with_transaction_returning_status`), isn't decremented again until
the the `ensure` block runs, and won't hit zero until the next time
`sync_with_transaction_state` is called.
|
|\ \
| |/
|/| |
Don't clear transaction state after manual rollback
|
| |
| |
| |
| |
| |
| |
| | |
If an `ActiveRecord::Rollback` error was raised by a persistence method
(e.g. in an `after_save` callback), this logic would potentially discard
the original state of the record from before the transaction, preventing
it from being restored later when the transaction was rolled back.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`after_initialize`
`becomes` creates new object and copies attributes from the receiver. If
new object has mutation tracker which is created in `after_initialize`,
it should be cleared since it is for discarded attributes.
But if the receiver doesn't have mutation tracker yet, it will not be
cleared properly.
It should be cleared regardless of whether the receiver has mutation
tracker or not.
Fixes #32867.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the documentation for the newly introduced (in 5.1) AR::Dirty
methods was misleading, as it stated the the new methods were aliases
for the old methods. This was false, and caused confusion when the
differences in their implementation became apparent.
This change attempts to describe the behaviour of these methods more
accurately, also noting when they are likely to be useful (i.e. before
or after saving a record).
This change also makes minor updates to consistently format the
documentation of this API, in accordance with the API Documentation
Guidelines.
|
|
|
|
| |
https://travis-ci.org/rails/rails/jobs/375326992#L1160-L1166
|
|
|
|
| |
Commit callbacks are intentionally disabled when errors occur when calling the callback chain in order to reset the internal record state. However, the implicit order of operations on the logic for checking if callbacks are disabled is wrong. The result is that callbacks can be unexpectedly when errors occur in transactions.
|
|
|
|
|
| |
It had been added at https://github.com/rails/arel/commit/05b5bb12270b32e094c1c879273e0978dabe5b3b
and removed at https://github.com/rails/arel/commit/db1bb4e9a728a437d16f8bdb48c3b772c3e4edb0
|
|
|
|
| |
`require 'rubygems'` is already required in Ruby 1.9 or later.
|
|\
| |
| | |
Allow a belonging to object to be created from a new record
|
| |
| |
| |
| | |
If a 'has one' object is created from a new record, an ActiveRecord::RecordNotSaved error is raised but this behavior was also applied to the reverse scenario.
|
| |
| |
| |
| |
| | |
Ensure that do not accidentally remove an index of different
definitions.
|
| | |
|
|/
|
|
|
|
|
| |
It will cause "undefined method `test_order' for ActiveSupport:Module
(NoMethodError)".
https://travis-ci.org/rails/rails/jobs/373472604#L1208
|
|
|
|
|
|
|
|
|
|
| |
not `Minitest::Test` to address `CustomCops/RefuteNot` and `CustomCops/AssertNot` offenses
for Arel test cases
Also including `ActiveSupport::Testing::Assertions` to `Arel::Spec`
and add test/unit backwards compatibility methods
Fixes #32720
|
|
|
|
|
| |
The merging order was accidentally changed at #32447. The original
intention is force `drop_table ... if_exists: true`. #28070.
|
|
|
|
|
| |
* Singular associations don't define `#association.nil?`
* Wrap with <tt> for each method, not the whole sentence
|
|\
| |
| | |
Use MethodCallAssertions instead of mocha expects
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Currently `ids_reader` doesn't respect dirty target when the target is
not loaded yet unlike `collection.size`. I believe the inconsistency is
a bug, fixes the `ids_reader` to behave consistently regardless of
whether target is loaded or not.
|
|\ \
| | |
| | | |
Loaded associations should not run a new query when size is called
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Already loaded associations were running an extra query when `size` was called on the association.
This fix ensures that an extra query is no longer run.
Update tests to use proper methods
|
|/ /
| |
| |
| |
| | |
This is to ensure that the behavior has not changed before and after
#31575.
|
|/
|
|
| |
Not required after https://github.com/rails/arel/pull/449
|
|
|
|
|
|
| |
Adds test case for failing issue
Moves set_value back to protected
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when tested with Ruby 2.5 or higher
```ruby
$ ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
$ bundle exec ruby -w -Itest test/cases/arel/collectors/bind_test.rb -n test_compile_gathers_all_bind_params
Run options: -n test_compile_gathers_all_bind_params --seed 24420
E
Error:
Arel::Collectors::TestBind#test_compile_gathers_all_bind_params:
NameError: uninitialized constant Arel::Collectors::Bind
Did you mean? Binding
test/cases/arel/collectors/bind_test.rb:15:in `collect'
test/cases/arel/collectors/bind_test.rb:19:in `compile'
test/cases/arel/collectors/bind_test.rb:31:in `test_compile_gathers_all_bind_params'
bin/rails test test/cases/arel/collectors/bind_test.rb:30
Finished in 0.002343s, 426.8559 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
$
```
It is likely due to Ruby 2.5 does not look up top level constant.
https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/
"Top-level constant look-up is no longer available."
|
|\
| |
| | |
Merge Arel
|
| | |
|
| | |
|