| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
provided.
|
| |
|
| |
|
|\
| |
| | |
Add a record to target before any callbacks loads the record
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`append_record` was added at 15ddd51 for not double adding the record.
But adding `append_record` (checking `@target.include?(record)`) caused
performance regression #27434. Instead of checking not double adding the
record, add a record to target before any callbacks loads the record.
Fixes #27434.
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| | |
kamipo/prevent_range_error_for_belongs_to_associations
Prevent `RangeError` for `belongs_to` associations
|
| |
| |
| |
| |
| |
| |
| |
| | |
Currently to access `belongs_to` associations raises a `RangeError` if
foreign key attribute has out of range value.
It should return a nil value rather than raising a `RangeError`.
Fixes #20140.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes casting of IDs to the data type of the association primary key,
rather than then the data type of the model's primary key. (Tests use a
string primary key on the association, rather than an int.)
Tests issue #20995
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
9c9fb19 changed the behaviour of the _ids= setters for associations to
raise an AssociationTypeMismatch when unknown IDs are given:
Class: <ActiveRecord::AssociationTypeMismatch>
Message: <"Developer(#43811860) expected, got NilClass(#16732720)">
This restores the original ActiveRecord::RecordNotFound exception with a
much clearer error message:
Class: <ActiveRecord::RecordNotFound>
Message: <"Couldn't find all Developers with 'id': (1, -9999) [WHERE \"contracts\".\"company_id\" = ?] (found 1 results, but was looking for 2)">
Fixes #25719
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch brings back the functionality of passing true to the
association proxy. The behavior was deprecated with #20888 and scheduled
for removal in Rails 5.1.
The deprecation mentioned that instead of `Article.category(true)` one
should use `article#reload.category`. Unfortunately the alternative does
not expose the same behavior as passing true to the reader
did. Specifically reloading the parent record throws unsaved changes and
other caches away. Passing true only affected the association.
This is problematic and there is no easy workaround. I propose to bring
back the old functionality by introducing this new reader method for
singular associations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently if `CollectionProxy` has more than one new record,
`CollectionProxy#uniq` result is incorrect.
And `CollectionProxy#uniq` was aliased to `distinct` in a1bb6c8b06db.
But the `uniq` method and the `SELECT DISTINCT` method are different
methods. The doc in `CollectionProxy` is for the `SELECT DISTINCT`
method, not for the `uniq` method.
Therefore, reverting the alias in `CollectionProxy` to fix the
inconsistency and to have the both methods.
|
| |
| |
| |
| |
| |
| | |
* Fixes TypeError when cache counter value equals nil
* Test case for counter cache on unloaded has_many association
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the changes in #25337, double save bugs are pretty much impossible,
so we can just lift this restriction with pretty much no change. There
were a handful of cases where we were relying on specific quirks in
tests that had to be updated. The change to has_one associations was due
to a particularly interesting test where an autosaved has_one
association was replaced with a new child, where the child failed to
save but the test wanted to check that the parent id persisted to `nil`.
I think this is almost certainly the wrong behavior, and I may change
that behavior later. But ultimately the root cause was because we never
remove the parent in memory when nullifying the child. This makes #23197
no longer needed, but it is what we'll do to fix some issues on 5.0
Close #23197
|
| | |
|
|\ \
| | |
| | |
| | | |
Fix for has_and_belongs_to_many & has_many_through associations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
partial_writes is false
This will fix #19663
Also with this fix, active record does not fire unnecassary update queries while partial_writes is true
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Using Constant and symbol class_name option for associations are valid but raises exception on HABTM associations.
There was a test case which tries to cover symbol class_name usage but doesn't cover correctly. Fixed both symbol usage and constant usage as well.
These are all working as expected now;
```
has_and_belongs_to_many :foos, class_name: 'Foo'
has_and_belongs_to_many :foos, class_name: :Foo
has_and_belongs_to_many :foos, class_name: Foo
```
Closes #23767
|
| | |
| | |
| | |
| | |
| | |
| | | |
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- CollectionAssociation#select was removed in
https://github.com/rails/rails/pull/25989 in favor of
QueryMethods#select but it caused a regression when passing arguments
to select and a block.
- This used to work earlier in Rails 4.2 and Rails 5. See gist
https://gist.github.com/prathamesh-sonpatki/a7df922273473a77dfbc742a4be4b618.
- This commit restores the behavior of Rails 4.2 and Rails 5.0.0 to
allow passing arguments and block at the same time but also deprecates
it.
- Because, these arguments do not have any effect on the output of
select when select is used with a block.
- Updated documentation to remove the example passing arguments and
block at the same time to `CollectionProxy#select`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was caused by 6d0d83a33f59d9415685852cf77818c41e2e2700. While the
bug it's trying to fix is handled if the association is loaded in an
after_(create|save) callback, it doesn't handle any cases that load the
association before the persistence takes place (validation, or before_*
filters). Instead of caring about the timing of persistence, we can just
ensure that we're not double adding the record instead.
The test from that commit actually broke, but it was not because the bug
has been re-introduced. It was because `Bulb` in our test suite is doing
funky things that look like STI but isn't STI, so equality comparison
didn't happen as the loaded model was of a different class.
Fixes #26661.
|
| |
| |
| |
| |
| |
| | |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.
For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.
Fixes #26320.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if the the association was previously loaded and then
the foreign key changed by itself, a #save call would trigger a
load of the new associated record during autosave. This is unnecessary
and the autosave code (in that case) didn't use the loaded record
anyways.
|
|\ \
| | |
| | |
| | | |
Preserve readonly flag only for readonly association
|
| | |
| | |
| | |
| | | |
Fixes #24093
|
|\ \ \
| | | |
| | | | |
Fix inconsistent the signature of finder methods for collection association
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`#second`, `#third`, etc finder methods was added in 03855e790de2224519f55382e3c32118be31eeff.
But the signature of these methods is inconsistent with the original
finder methods. And also the signature of `#first` and `#last` methods
is different from the original. This commit fixes the inconsistency.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
kamipo/finder_bang_method_should_call_non_bang_method
Finder bang method should call non bang method
|
| |/ / /
| | | |
| | | |
| | | | |
Otherwise CollectionProxy's bang methdos cannot respect dirty target.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current behaviour of checking if there is a LEFT OUTER JOIN arel
node to detect if we are doing eager_loading is wrong. This problem
wasn't frequent before as only some pretty specific cases would add
a LEFT OUTER JOIN arel node. However, the recent new feature
left_outer_joins also add this node and made this problem happen
frequently.
Since in the perform_calculation function, we don't have access to
eager_loading information, I had to extract the logic for the distinct
out to the calculate method.
As I was in the file for left_outer_join tests, I fixed a few that had
bugs and I replaced some that were really weak with something that
will catch more issues.
In relation tests, the first test I changed would have failed if it
had validated the hash returned by count instead of just checking how
many pairs were in it. This is because this merge of join currently
transforms the join node into an outer join node, which then made
count do a distinct. So before this change, the return was
{1=>1, 4=>1, 5=>1}.
|
|\ \ \
| | | |
| | | | |
When calling association.find RecordNotFound is now raised with the s…
|
| | | |
| | | |
| | | |
| | | | |
argument as when we do it in Record.find (primary_key, id and model).
|
|\ \ \ \
| | | | |
| | | | | |
`CollectionProxy#take` should respect dirty target
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
`#first`, `#second`, ..., `#last` methods respects dirty target. But
`#take` doesn't respect it. This commit fixes the inconsistent behavior.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| | |
| | |
| | |
| | | |
Hash syntax auto-correcting breaks alignments. 411ccbdab2608c62aabdb320d52cb02d446bb39c
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| | |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/association_name_is_the_same_as_join_table_name
Correctly return `associated_table` when `associated_with?` is true
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`AssociationQueryHandler` requires `association` initialized
`TableMetadata` even if `table_name == arel_table.name`.
Fixes #25689.
|
| | |
| | |
| | |
| | | |
These test cases tests exactly mutating loaded target.
|
| | |
| | |
| | |
| | | |
This is not a test case.
|