* 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]
ruby/ruby@989e07c features switching `Range#===` to use internal `r_cover_p`
instead of rubyland `include?`. This breaks expected behavior of
`ActiveSupport::CoreExt::Range` documented since at least 8b67a02.
This patch adds overrides on `Range#cover?` and `Range#===` and places all
three in a single module, `CompareWithRange`.
*Requiring core_ext/range/include_range now causes a deprecation warnning*
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_keysFixes#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.
```
In the app I'm working on I've wished that index_by had a buddy that would
assign the hash value instead of the key multiple times.
Enter index_with. Useful when building a hash from a static list of
symbols. Before you'd do:
```ruby
POST_ATTRIBUTES.map { |attr_name| [ attr_name, public_send(attr_name) ] }.to_h
```
But now that's a little clearer and faster with:
````ruby
POST_ATTRIBUTES.index_with { |attr_name| public_send(attr_name) }
```
It's also useful when you have an enumerable that should be converted to a hash,
but you don't want to muddle the code up with the overhead that it takes to create
that hash. So before, that's:
```ruby
WEEKDAYS.each_with_object(Hash.new) do |day, intervals|
intervals[day] = [ Interval.all_day ]
end
```
And now it's just:
```ruby
WEEKDAYS.index_with([ Interval.all_day ])
```
It's also nice to quickly get a hash with either nil, [], or {} as the value.
In response to https://github.com/rails/rails/issues/32917
In the current implementation, ActiveStorage passes all options to the underlying processor,
including when a key has a value of false.
For example, passing:
```
avatar.variant(resize: "100x100", monochrome: false, flip: "-90")
```
will return a monochrome image (or an error, pending on ImageMagick configuration) because
it passes `-monochrome false` to the command (but the command line does not allow disabling
flags this way, as usually a user would omit the flag entirely to disable that feature).
This fix only passes those keys forward to the underlying processor if the value responds to
`present?`. In practice, this means that `false` or `nil` will be filtered out before going
to the processor.
One possible use case would be for a user to be able to apply different filters to an avatar.
The code might look something like:
```
variant_options = {
monochrome: params[:monochrome],
resize: params[:resize]
}
avatar.variant(*variant_options)
```
Obviously some sanitization may be beneficial in a real-world scenario, but this type of
configuration object could be used in many other places as well.
- Add removing falsy values from varaints to changelog
- The entirety of #image_processing_transformation inject block was wrapped in `list.tap`
to guard against the default `nil` being returned if no conditional was called.
- add test for explicitly true variant options
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
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.
Generated attachment getter and setter methods are created within
the model's `GeneratedAssociationMethods` module to allow overriding
and composition using `super`.
Includes tests for new functionality.
Co-authored-by: Josh Susser <josh@hasmanythrough.com>
Co-authored-by: Jamon Douglas <terrildouglas@gmail.com>
### Steps to reproduce
Using Rails 5.2.0
When following this example:
http://api.rubyonrails.org/classes/ActiveStorage/Variant.html
`avatar.variant(resize: "100x100", monochrome: true, flip: "-90")`
### Expected behavior
Image should be rendered as flipped.
### Actual behavior
I get an error:
> failed with error: gm mogrify: Unrecognized option (-90).
### Fix:
According to: https://github.com/minimagick/minimagick the option should be called rotate:
`avatar.variant(resize: "100x100", monochrome: true, rotate: "-90")`
So **flip** changed to **rotate**.
### System configuration
**Rails version**: 5.2.0
**Ruby version**: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
