| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
kamipo/remove_unnecessary_select_for_collection_proxy
Remove unnecessary `select` method for `CollectionProxy`
|
| |
| |
| |
| |
| |
| |
| | |
Currently `CollectionProxy` inherits `Relation` and `Relation` includes
`QueryMethods`. This method is completely duplicated.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/relation/query_methods.rb#L271-L275
|
|\ \
| | |
| | |
| | | |
Preserve readonly flag only for readonly association
|
| | |
| | |
| | |
| | | |
Fixes #24093
|
| |/
|/|
| |
| |
| | |
Currently `CollectionProxy` inherits `Relation` therefore we can use
its own methods rather than delegating to collection association.
|
|\ \
| | |
| | | |
`pluck` should use `records` (`load_target`) when `loaded?` is true
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`#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.
|
| | |
| | |
| | |
| | |
| | | |
`#first`, `#second`, ..., `#last` methods respects dirty target. But
`#take` doesn't respect it. This commit fixes the inconsistent behavior.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| | |
| | |
| | |
| | | |
Some case expressions remain, need to think about those ones.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| | |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33
See also #26022.
|
|/
|
|
|
|
|
| |
Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33
|
|\
| |
| | |
`FinderMethods` uses `records` (`load_target`) when `loaded?` is true
|
| | |
|
|\ \
| | |
| | | |
Fix to `CollectionProxy#load` does `load_target`
|
| |/ |
|
| |
| |
| |
| | |
Fixes #25653.
|
|/
|
|
| |
`send` is unnecessary.
|
|
|
|
|
|
| |
association scope
Fixes #25732.
|
|\
| |
| |
| |
| | |
kamipo/move_warning_about_composite_primary_key_to_attribute_methods_primary_key
Move the warning about composite primary key to `AttributeMethods::PrimaryKey`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Actually schema dumper/creation supports composite primary key (#21614).
Therefore it should not show the warning about composite primary key in
connection adapter.
This change moves the warning to `AttributeMethods::PrimaryKey` and
suppress the warning for habtm join table.
Fixes #25388.
|
| | |
|
|/
|
|
|
| |
This nested if checked the same value as the containing case statement.
Moved the code in the if/else into when/else in the containing case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `exists?` does some hackery where it assumes that we can join
onto anything that we passed to `eager_load` or `includes`, which
doesn't work if we are joining onto a polymorphic association.
Actually figuring out if we want to include something would require
knowledge deep within the join dependency module, which is hard to pull
up. The simplest solution is just to pass a flag down that says we're
not actually going to try to eager load any of the data. It's not the
solution I'd like, but that code really needs to be untangled before we
can do much with it.
This is another attempt at 6d5b1fd which should address the concerns
that led to reverting it in 4ecabed.
|
|\
| |
| | |
Add missing `the`
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| | |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
|\ \
| | |
| | | |
Forward ActiveRecord::Relation#count to Enumerable#count if block given
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The error message that we give today makes this error difficult to debug
if you receive it. I have no clue why we're printing the object ID of
the class (the commit doesn't give context), but I've left it as it was
deliberate.
|
| |/
|/| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 04ac5655be91f49cd4dfe2838df96213502fb274 I assumed that we would
never want to pass the "table_name.column_name" form to where with a
symbol. However, in Ruby 2.2 and later, you can quote symbols using the
new hash syntax, so it's a semi-reasonable thing to do if we want to
support the dot notation (which I'd rather deprecate, but that would be
too painful of a migration).
Instead we've changed the definition of "this is a table name with a
dot" to when the value associated is a hash. It would make very little
sense to write `where("table_name.column_name": { foo: :bar })` in any
scenario (other than equality for a JSON column which we don't support
through `where` in this way).
Close #24514.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Fix undefined method `owners' for NullPreloader:Class
Fixing undefined method `owners' for
ActiveRecord::Associations::Preloader::NullPreloader:Class
* Use Ruby 1.9 hash format
Use Ruby 1.9 hash format
#24192
[Rafael Mendonça França + Ladislav Smola]
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue occured because associations now call `where` directly, and a
dot in the key name for `where` means nested tables. For this fix, we
now pass the table name as a symbol, and do not attempt to expand
symbols containing a dot.
This is a temporary fix. I do not think we should support table names
containing a dot, as it has a special meaning in most backends, as well
as most APIs that involve table names. This commit does not include a
test, as I am going to deprecate table names containing dots in the
following commit.
Fixes #24367
|
|\
| |
| |
| |
| | |
RochesterinNYC/better-error-message-for-includes-relations-missing
Improve error message for missing relations for includes and eager_load
|
| |
| |
| |
| | |
relations
|
| |
| |
| |
| |
| | |
Introduce a predicate method that doesn't need to build a scope chain,
but also hides the data structure used for representing the scope chain.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes #23934.
This is a forward port of ac832a43b4d026dbad28fed196d2de69ec9928ac
Previously the scope of all associations with extensions were wrapped in
an instance dependent proc. This made it impossible to preload such
associations.
|
|\ \
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | |
| | | | |
Mutating the result of Relation#to_a should not affect the relation
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
habtm join tables commonly have two id columns and it's OK to make those
two id columns a primary key. This commit eliminates the warnings for
join tables that have this setup.
ManageIQ/manageiq#6713
|