| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The `find_each`, `find_in_batches` and `in_batches` APIs usually operate
on large numbers of records, where it's preferable not to load them all
into memory at once.
If the query cache is enabled, it will hold onto the query results until
the end of the execution context (request/job), which means the memory
used is still proportional to the total number of records. These queries
are typically not repeated, so the query cache isn't desirable here.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
|\
| |
| |
| | |
Enforce frozen string in Rubocop
|
| | |
|
|\ \
| |/
|/|
| | |
Make ActiveSupport frozen-string-literal friendly.
|
| | |
|
|\ \
| | |
| | | |
`Relation#locked?` should not build arel
|
| |/
| |
| |
| |
| | |
The delegation was needed since passing `relation` with
`relation.bound_attributes`. It should use `relation.arel` in that case.
|
|/ |
|
|
|
|
| |
Fixes #29025.
|
| |
|
|
|
|
| |
To ease to customize a relation for `exists?`.
|
|
|
|
|
|
|
|
| |
This reverts commit a680a5814184e2f37c4686aa53d0ad3c7fb6b1ee, reversing
changes made to 842f67dd242e738419f27e752ea7dcd0bbe87b6d.
Reason: I can't resist to the joke, so better to keep it there
https://github.com/rails/rails/pull/28598#issuecomment-290945339.
|
|
|
|
|
|
|
| |
silly method gets a silly doc fix,
or I'm missing an even sillier joke and I'm about to get schooled.
BUT I'm pretty sure this is some serious Beaudrillard simulacrum, though.
I'm just doing my part to spread the gospel of Douglas Adams.
|
|
|
|
|
| |
If the `index` exceeds a `limit`, simply return an empty result without
querying the database.
|
| |
|
| |
|
|
|
|
| |
find and exists?
|
| |
|
|
|
|
|
|
| |
Some methods were added to public API in
5b14129d8d4ad302b4e11df6bd5c7891b75f393c and they should be not part of
the public API.
|
| |
|
|
|
|
| |
Raise `ActiveRecord::RangeError` when values that executed are out of range.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Records fetching order is very important for performance if `limit` is
presented. Should not except the order in the case.
And `exists?` replaces select list to `1 AS one` therefore `:distinct`
is useless (`DISTINCT 1 AS one`). And PostgreSQL raises the following
error if `:distinct` and `:order` are used in the same time.
```
ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list
```
|
| |
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
|
|
|
|
|
| |
Currently `CollectionProxy` inherits `Relation` therefore we can use
its own methods rather than delegating to collection association.
|
|
|
|
| |
Otherwise CollectionProxy's bang methdos cannot respect dirty target.
|
|\
| |
| | |
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).
|
| |
| |
| |
| |
| |
| |
| |
| | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|/
|
|
|
|
| |
`find_nth` is protected method, therefore `offset` has not been passed
anywhere. `find_nth_with_limit_and_offset` is unnecessary anymore
because `offset` has not been passed.
|
|
|
|
| |
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.
|
| |
|
|\
| |
| | |
Prevent `RangeError` for `FinderMethods#exists?`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`FinderMethods#exists?` should return a boolean rather than raising an
exception.
`UniquenessValidator#build_relation` catches a `RangeError` because it
includes type casting due to a string value truncation. But a string
value truncation was removed at #23523 then type casting in
`build_relation` is no longer necessary. aa06231 removes type casting in
`build_relation` then a `RangeError` moves to `relation.exists?`.
This change will remove the catching a `RangeError`.
|
|/
|
|
|
|
|
|
|
|
| |
`construct_relation_for_association_calculations` pass a string value to
`construct_join_dependency` when setting a string value in `from`.
It should not pass a string value, but always `joins_values`.
Related #14834, #19452.
Fixes #24193.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
|
|
|
|
| |
We should use #find_or_initialize_by and #find_or_create_by because #first_or_initialize and #first_or_create methods are not the public API
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
| |
|
|\
| |
| | |
Fix AR::Relation#last bugs instroduced in 7705fc
|
| |
| |
| |
| | |
instead of loading the relation into memory
|
|/ |
|