| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
`pluck` should use `records` (`load_target`) when `loaded?` is true
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\
| |
| | |
`FinderMethods` uses `records` (`load_target`) when `loaded?` is true
|
| | |
|
|\ \
| | |
| | | |
Fix to `CollectionProxy#load` does `load_target`
|
| |/ |
|
|/
|
|
| |
`send` is unnecessary.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We deprecate the support for passing an argument to force reload in
6eae366d0d2e5d5211eeaf955f56bd1dc6836758. That led to several
deprecation warning when running Active Record test suite.
This commit silence the warnings by properly calling `#reload` on the
association proxy or on the association object instead. However, there
are several places that `ActiveSupport::Deprecation.silence` are used as
those tests actually tests the force reload functionality and will be
removed once `master` is targeted next minor release (5.1).
|
|
|
|
| |
These methods are nodoc so we should not document them.
|
|\
| |
| |
| | |
Isolate access to @associations_cache and @aggregations_cache to the Associations and Aggregations modules, respectively.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Associations and Aggregations modules, respectively.
This includes replacing the `association_cache` accessor with a more
limited `association_cached?` accessor and making `clear_association_cache`
and `clear_aggregation_cache` private.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only place it was accessed was in tests. Many of them have another
way that they can test their behavior, that doesn't involve reaching
into internals as far as they did. `AssociationScopeTest` is testing a
situation where the where clause would have one bind param per
predicate, so it can just ignore the predicates entirely. The where
chain test was primarly duplicating the logic tested on `WhereClause`
directly, so I instead just make sure it calls the appropriate method
which is fully tested in isolation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes the need to duplicate much of the logic in `WhereClause`
and `PredicateBuilder`, simplifies the code, removes the need for the
connection adapter to be continuously passed around, and removes one
place that cares about the internal representation of `bind_values`
Part of the larger refactoring to change how binds are represented
internally
[Sean Griffin & anthonynavarre]
|
| | |
|
| |
| |
| |
| | |
Fixes #18237
|
| | |
|
|/
|
|
|
| |
`Computer` class needs to be require
See #17217 for more details
|
|
|
|
|
|
|
|
|
|
| |
Closes #16684.
This is achieved by always generating `GeneratedAssociationMethods` when
`ActiveRecord::Base` is subclassed. When some of the included modules
of `ActiveRecord::Base` were reordered this behavior was broken as
`Core#initialize_generated_modules` was no longer called. Meaning that
the module was generated on first access.
|
| |
|
|
|
|
| |
Need to define #reset on CollectionProxy.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppose Man has_many interests, and inverse_of is used.
Man.first.interests.first.man will correctly execute two queries,
avoiding the need for a third query when Interest#man is called. This is
because CollectionAssociation#first calls set_inverse_instance.
However Man.first.interests.where("1=1").first.man will execute three
queries, even though this is obviously a subset of the records in the
association.
This is because calling where("1=1") spawns a new Relation object from
the CollectionProxy object, and the Relation has no knowledge of the
association, so it cannot set the inverse instance.
This commit solves the problem by making relations spawned from
CollectionProxies return a new Relation subclass called
AssociationRelation, which does know about associations. Records loaded
from this class will get the inverse instance set properly.
Fixes #5717.
Live commit from La Conf! :sparkles:
|
| |
|
|
|
|
|
|
|
|
| |
This reimplements the behaviour of Rails 3, as I couldn't see why we
shouldn't cache the object, and @alindeman had a good use case for
caching it:
https://github.com/rails/rails/commit/c86a32d7451c5d901620ac58630460915292f88b#commitcomment-2784312
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #7364.
Collection associations behave similar to Arrays. However there is no
way to prepend records. And to append one should use `<<`. Before this
patch `#append` and `#prepend` did not add the record to the loaded
association.
`#append` now behaves like `<<` and `#prepend` is not defined.
|
|
|
|
| |
Fixes #7418.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be used to get a Relation from an association.
Previously we had a #scoped method, but we're deprecating that for
AR::Base, so it doesn't make sense to have it here.
This was requested by DHH, to facilitate code like this:
Project.scope.order('created_at DESC').page(current_page).tagged_with(@tag).limit(5).scoping do
@topics = @project.topics.scope
@todolists = @project.todolists.scope
@attachments = @project.attachments.scope
@documents = @project.documents.scope
end
|
|
|
|
|
|
| |
It has been moved to active_record_deprecated_finders.
Use #to_a instead.
|
|
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
|
|
|
| |
Closes #1190
|
| |
|
|
|
|
| |
Base#scoped
|
|
|
|
| |
things
|
|
|
|
|
|
| |
See the CHANGELOG for details.
Fixes #950.
|
|
|
|
| |
This reverts commit c99d507fccca2e9e4d12e49b4387e007c5481ae9.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of generating association methods directly in the model
class, they are generated in an anonymous module which
is then included in the model class. There is one such module
for each association. The only subtlety is that the
generated_attributes_methods module (from ActiveModel) must
be forced to be included before association methods are created
so that attribute methods will not shadow association methods.
|