| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| | |
Honour joining model order in `has_many :through` associations when
eager loading
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
association when eager loading.
Previously, eager loading a `has_many :through` association with no
defined order would return the records in the natural order of the
database. Now, these records will be returned in the order that the
joining record is returned, in case there is a defined order there.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I ran into an issue where validations on a suppressed record were
causing validation errors to be thrown on a record that was never going
to be saved.
There isn't a reason to run the validations on a record that doesn't
matter.
This change moves the suppressor up the chain to be run on the `save` or
`save!` in the validations rather than in persistence. The issue with
running it when we hit persistence is that the validations are run
first, then we hit persistance, and then we hit the suppressor. The
suppressor comes first.
The change to the test was required since I added the
`validates_presence_of` validations. Adding this alone was enough to
demonstrate the issue. I added a new test to demonstrate the new
behavior is explict.
|
| |\ \
| | |
| | | |
Fix issue #23625
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This resolves a bug where if the primary key used is not `id` (ex:
`uuid`), and has a `validates_uniqueness_of` in the model, a uniqueness error
would be raised. This is a partial revert of commit `119b9181ece399c67213543fb5227b82688b536f`, which introduced this behavior.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
different types.
When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))
This is fixed to properly look for any records matching both type and id:
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Allow `joins` to be unscoped
Fixes #13775
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| | |
Fixes #23209
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes incorrect assumptions made by e991c7b that we can assume the
DB is already casting the value for us. The enum type needs additional
information to perform casting, and needs a subtype.
I've opted not to call `super` in `cast`, as we have a known set of
types which we accept there, and the subtype likely doesn't accept them
(symbol -> integer doesn't make sense)
Close #23190
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
glittershark/if-and-unless-in-secure-token"
This reverts commit 224eddfc0eeff6555ae88691306e61c7a9e8b758, reversing
changes made to 9d681fc74c6251d5f2b93fa9576c9b2113116680.
When merging the pull request, I misunderstood `has_secure_token` as declaring a model
has a token from birth and through the rest of its lifetime.
Therefore, supporting conditional creation doesn't make sense. You should never mark a
model as having a secure token if there's a time when it shouldn't have it on creation.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given a default_scope on a parent of the current class, where that
parent is not the base class, the parent's STI condition would become
attached to the evaluated default scope, and then override the child's
own STI condition.
Instead, we can treat the STI condition as though it is a default scope,
and skip it in this situation: the scope will be merged into the base
relation, which already contains the correct STI condition.
Fixes #22426.
|
| | |
| |
| |
| |
| | |
Pass through :if and :unless options from has_secure_token to the
generated before_create callback
|
| | |
| |
| |
| |
| | |
When same association is loaded in the model creation callback
The new object is inserted into association twice
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, if
`ActiveRecord::Base.belongs_to_required_by_default` is set to `true`,
then creating a record through `has_and_belongs_to_many` fails with the
cryptic error message `Left side must exist`. This is because
`inverse_of` isn't working properly in this case, presumably since we're
doing trickery with anonymous classes in the middle.
Rather than following this rabbit hole to try and get `inverse_of` to
work in a case that we know is not publicly supported, we can just turn
off this validation to match the behavior of 4.2 and earlier.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm making this commit separately because this has failing tests and
style nitpicks that I'd like to make as individual commits, to make the
changes I'm making explicit.
We still want a single merge commit at the end, however.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the newer method used for discriminating new records did not
use the older and more robust method used for instantiating
existing records, but did have a better post-check to ensure
the sublass was in the hierarchy. so move the descendants check
to find_sti_class, and then simply call find_sti_class from
subclass_from_attributes
now with fixed specs
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 60c9701269f5b412849f1a507df61ba4735914d7, reversing
changes made to 6a25202d9ea3b4a7c9f2d6154b97cf8ba58403db.
Reason: Broken build
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This triggers the JoinDependency work to reflect on the associations
and trigger an error as follows:
ActiveRecord::ConfigurationError: Association named 'account' was
not found on Company; perhaps you misspelled it?
Fix Company.of_first_firm joins association name
Should be `Company.joins(:accounts)` not `Company.joins(:account)`.
Do the same for Client.of_first_firm
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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]
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* When tried to use `Company#accounts` test/models/company.rb I got:
```
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column:
accounts.company_id: SELECT COUNT(*) AS count_all, "companies"."firm_id"
AS companies_firm_id FROM "companies" INNER JOIN "accounts" ON
"accounts"."company_id" = "companies"."id" GROUP BY "companies"."firm_id"
```
* The refactor on Calculations class was just to simplify the code
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.
The goal is to provide the following introspection methods on the
connection:
* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
robertjlooby/fix_overwriting_by_dynamic_finders"
This reverts commit d5ba9a42a6e93b163a49f99d739aa56820e044d0, reversing
changes made to 30c503395bf6bf7db1ec0295bd661ce644628db5.
Reason: This generate the dynalic finders more than one time
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
put dynamic matchers on GeneratedAssociationMethods instead of model
|
| | |/ / / |
|
| | | | |
| | | |
| | | | |
`lengh` should be `length`
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously has_many associations assumed a counter_cache was to be used
based on the presence of an appropriately named column. This is
inconsistent, since the inverse belongs_to association will not make
this assumption. See issues #19042 #8446.
This commit checks for the presence of the counter_cache key in the
options of either the has_many or belongs_to association as well as
ensuring that the *_count column is present.
|
| |\ \ \ \
| | | | |
| | | | | |
Prevent duplicating `where` clauses
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
class
Fixes #19528
fix for mysql2 test
better test
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the through class has default scopes we should skip the statement
cache.
Closes #20745.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Fix misleading errors for has_one through relations
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes it more clear that they are reserved keywords and also it
seems less redundant as the line already starts with the call to the
`enum` method.
|
| |/ / / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As per the docs, `mark_for_destruction` should do nothing if `autosave`
is not set to true. We normally persist associations on a record no
matter what if the record is a new record, but we were always skipping
records which were `marked_for_destruction?`.
Fixes #20882
|
