| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This solves the following error:
ActiveRecord::StatementInvalid: Could not find table 'guitars'
It seems that the table structure of the `Guitar` model has not been
necessary until now. Due to the wrong table name the model was not
correctly linked to the table.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialize_attributes
If argument of `build_record` has key and value which is same as
default value of database, we should also except the key from
`create_scope` in `initialize_attributes`.
Because at first `build_record` initialize record object with argument
of `build_record`, then assign attributes derived from Association's scope.
In this case `record.changed` does not include the key, which value is
same as default value of database, so we should add the key to except list.
Fix #21893.
|
|\
| |
| |
| |
| |
| | |
sebjacobs/support-bidirectional-destroy-dependencies
Add support for bidirectional destroy dependencies
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prior to this commit if you defined a bidirectional relationship
between two models with destroy dependencies on both sides, a call to
`destroy` would result in an infinite callback loop.
Take the following relationship.
class Content < ActiveRecord::Base
has_one :content_position, dependent: :destroy
end
class ContentPosition < ActiveRecord::Base
belongs_to :content, dependent: :destroy
end
Calling `Content#destroy` or `ContentPosition#destroy` would result in
an infinite callback loop.
This commit changes the behaviour of `ActiveRecord::Callbacks#destroy`
so that it guards against subsequent callbacks.
Thanks to @zetter for demonstrating the issue with failing tests[1].
[1] rails#13609
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Errors can be indexed with nested attributes
Close #8638
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`has_many` can now take `index_errors: true` as an
option. When this is enabled, errors for nested models will be
returned alongside an index, as opposed to just the nested model name.
This option can also be enabled (or disabled) globally through
`ActiveRecord::Base.index_nested_attribute_errors`
E.X.
```ruby
class Guitar < ActiveRecord::Base
has_many :tuning_pegs
accepts_nested_attributes_for :tuning_pegs
end
class TuningPeg < ActiveRecord::Base
belongs_to :guitar
validates_numericality_of :pitch
end
```
- Old style
- `guitar.errors["tuning_pegs.pitch"] = ["is not a number"]`
- New style (if defined globally, or set in has_many_relationship)
- `guitar.errors["tuning_pegs[1].pitch"] = ["is not a number"]`
[Michael Probber, Terence Sun]
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
This is a separate commit, as it is not just a changelog conflict. Want
to point out the changes in the code
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
use only object_id instead parent class and parent id
test cases
assert_equal
use table name in references
fix minor problems
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`inverse_of` on through associations was accidently removed/caused to
stop working in commit f8d2899 which was part of a refactoring on
`ThroughReflection`.
To fix we moved `inverse_of` and `check_validity_of_inverse!` to the
`AbstractReflection` so it's available to the `ThroughReflection`
without having to dup any methods. We then need to delegate `inverse_name`
method in `ThroughReflection`. `inverse_name` can't be moved to
`AbstractReflection` without moving methods that set the instance
variable `@automatic_inverse_of`.
This adds a test that ensures that `inverse_of` on a `ThroughReflection`
returns the correct class name, and the correct record for the inverse
relationship.
Fixes #21692
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And we are passing them as separate types in the query, which means 0
precision is still not supported by older versions of MySQL. I also
missed a handful of other cases where they need to be conditionally
applied.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifically, versions of MySQL prior to 5.6 do not support this, which
is what's used on Travis by default. The method `mysql_56?` appeared to
only ever be used to conditionally apply subsecond precision, so I've
generalized it and used it more liberally.
This should fix the test failures caused by #20317
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Timestamp column can have less precision than ruby timestamp
In result in how big a fraction of a second can be stored in the
database.
m = Model.create!
m.created_at.usec == m.reload.created_at.usec
# => false
# due to different seconds precision in Time.now and database column
If the precision is low enough, (mysql default is 0, so it is always low
enough by default) the value changes when model is reloaded from the
database. This patch fixes that issue ensuring that any timestamp
assigned as an attribute is converted to column precision under the
attribute.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes #21488
[Sean Griffin & johanlunds]
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since after 87d1aba3c `dependent: :destroy` callbacks on has_one
assocations run *after* destroy, it is possible that a nullification is
attempted on an already destroyed target:
class Car < ActiveRecord::Base
has_one :engine, dependent: :nullify
end
class Engine < ActiveRecord::Base
belongs_to :car, dependent: :destroy
end
> car = Car.create!
> engine = Engine.create!(car: car)
> engine.destroy! # => ActiveRecord::ActiveRecordError: cannot update a
> destroyed record
In the above case, `engine.destroy!` deletes `engine` and *then* triggers the
deletion of `car`, which in turn triggers a nullification of `engine.car_id`.
However, `engine` is already destroyed at that point.
Fixes #21223.
|
|\ \ \
| | | |
| | | |
| | | | |
Require explicit counter_cache option for has_many
|
| |/ /
| | |
| | |
| | |
| | | |
Assert that counter_cache behaviour is not used on belongs_to or
has_many associations if the option is not given explicitly.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the through class has default scopes we should skip the statement
cache.
Closes #20745.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also removes a false positive test that depends on the fixed bug:
At this time, counter_cache does not work with polymorphic relationships
(which is a bug). The test was added to make sure that no
StaleObjectError is raised when the car is destroyed. No such error is
currently raised because the lock version is not incremented by
appending a wheel to the car.
Furthermore, `assert_difference` succeeds because `car.wheels.count`
does not check the counter cache, but the collection size. The test will
fail if it is replaced with `car.wheels_count || 0`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This code is so fucked. Things that cause this bug not to replicate:
- Defining the validation before the association (we end up calling
`uniq!` on the errors in the autosave validation)
- Adding `accepts_nested_attributes_for` (I have no clue why. The only
thing it does that should affect this is adds `autosave: true` to the
inverse reflection, and doing that manually doesn't fix this).
This solution is a hack, and I'm almost certain there's a better way to
go about it, but this shouldn't cause a huge hit on validation times,
and is the simplest way to get it done.
Fixes #20874.
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #17511 and #17415
|
| | |
| | |
| | |
| | | |
abstract base class.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If there was a polymorphic hm:t association with a scope AND second
non-scoped hm:t association on a model the polymorphic scope would leak
through into the call for the non-polymorhic hm:t association.
This would only break if `hotel.drink_designers` was called before
`hotel.recipes`. If `hotel.recipes` was called first there would be
no problem with the SQL.
Before (employable_type should not be here):
```
SELECT COUNT(*) FROM "drink_designers" INNER JOIN "chefs" ON
"drink_designers"."id" = "chefs"."employable_id" INNER JOIN
"departments" ON "chefs"."department_id" = "departments"."id" WHERE
"departments"."hotel_id" = ? AND "chefs"."employable_type" = ?
[["hotel_id", 1], ["employable_type", "DrinkDesigner"]]
```
After:
```
SELECT COUNT(*) FROM "recipes" INNER JOIN "chefs" ON "recipes"."chef_id"
= "chefs"."id" INNER JOIN "departments" ON "chefs"."department_id" =
"departments"."id" WHERE "departments"."hotel_id" = ? [["hotel_id", 1]]
```
From the SQL you can see that `employable_type` was leaking through when
calling recipes. The solution is to dup the chain of the polymorphic
association so it doesn't get cached. Additionally, this follows
`scope_chain` which dup's the `source_reflection`'s `scope_chain`.
This required another model/table/relationship because the leak only
happens on a hm:t polymorphic that's called before another hm:t on the
same model.
I am specifically testing the SQL here instead of the number of records
becasue the test could pass if there was 1 drink designer recipe for the
drink designer chef even though the `employable_type` was leaking through.
This needs to specifically check that `employable_type` is not in the SQL
statement.
|
|\ \
| | |
| | |
| | |
| | | |
rebyn/fix/17161-remove-objs-from-has_many-updates-fields
Add specs for adding-to/clear has_many collections’s behavior on `updated_at`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are behaviors mentioned in #17161 that:
1. are not documented properly, and
2. don't have specs
This commit addresses the spec absence. For has_many collections,
1. addition (<<) should update the associated object's updated_at (if any)
2. .clear, depending on options[:dependent], calls delete_all, destroy_all, or nullifies the associated object(s)' foreign key.
|
| | | |
|
| | |
| | |
| | |
| | | |
onwards.
|
|\ \ \
| | | |
| | | | |
Fix STI for fixtures from multi-files
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
- Add check for not deleting previously created fixtures, to overcome sti fixtures from multiple files
- Added fixtures and fixtures test to verify the same
- Fixed wrong fixtures duplicating data insertion in same table
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
These callbacks will already have been defined when the association was
built. The check against `reflection.autosave` happens at call time, not
at define time, so simply modifying the reflection is sufficient.
Fixes #18704
|
| | |
|
| |
| |
| |
| |
| |
| | |
Update SecureToken Docs
Add Changelog entry for has_secure_token [ci skip]
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
To be possible to use a custom column name to save/read the polymorphic
associated type in a has_many or has_one polymorphic association, now users
can use the option :foreign_type to inform in what column the associated object
type will be saved.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
|/
|
|
| |
We were relying on hash inequality in tests
|
|
|
|
|
| |
This fixes <"SQLite3::SQLException: no such column: legacy_things.person_id: SELECT \"legacy_things\".* FROM \"legacy_things\" WHERE \"legacy_things\".\"person_id\" = ?">
in OptimisticLockingTest#test_lock_destroy
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with dynamic conditions.
Fixes #16128
This bug was introduced in https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d
so it's present from 4.1.2-rc1 and after.
https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d
merges any relation scopes passed as proc objects to the relation,
but does *not* take into account the arity of the lambda.
To reproduce: https://gist.github.com/Agis-/5f1f0d664d2cd08dfb9b
|
|
|
|
|
|
|
| |
As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.
|
| |
|
|
|
|
| |
by using shorter attribute names.
|
|
|
|
| |
This reverts commit e84799d, e31104c and e6ca8e2
|
|
|
|
|
|
| |
This was previously fixed in e84799d but broken in 3f596f8. This commit
reintroduced the conditional that prevents the foreign keys from being
added to MySQL databases.
|
| |
|