| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
|
|
|
|
|
|
|
|
|
| |
Delegation of some `Array` methods was removed in commit 9d79334. That
change did add explicit delegation of a few methods that `Array` has but
which aren't on `Enumerable`. However, a few non-mutation methods were
omitted. This adds `Array` delegation of `#in_groups`, `#in_groups_of`,
`#shuffle` and `#split`. This allows things like
`MyThing.all.in_groups_of(3) { ... }` to continue working as they did
before commit 9d79334.
|
|\
| |
| |
| |
| | |
phuibonhoa/phuibonhoa/polymorphic_where_multiple_types
Fixed `where` for polymorphic associations when passed an array containing different types.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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))
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
AR::Relation#or
- Previously it used to show error message
<"undefined method `limit_value' for {:title=>\"Rails\"}:Hash">
- Now it shows following error message.
>> Post.where.not(name: 'DHH').or(name: 'Tenderlove')
ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead.
- Fixes #23714.
|
| |
|
|\
| |
| | |
Fix AR::Relation#last bugs instroduced in 7705fc
|
| |
| |
| |
| | |
instead of loading the relation into memory
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the following warnings.
```
activerecord/lib/active_record/relation/finder_methods.rb:252: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:258: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:268: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:274: warning: ambiguous first argument; put parentheses or a space even after `-' operator
```
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 9f3730a516f30beb0050caea9539f8d6b808e58a, reversing
changes made to 2637fb75d82e1c69333855abd58c2470994995d3.
There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.
|
|
|
|
| |
instead of loading relation
|
|\
| |
| | |
Consistently warn that passing an offset to `find_nth` is deprecated
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
@bogdan pointed out that a `loaded?` relation would not warn that the supplied
offset would be removed. This fixes that oversight.
https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834
Although this second argument is probably not widely used, and would be
ignored anyway in the loaded? case, this could protect callers from gotchas.
[Ben Woosley & Victor Kmita]
|
| |
| |
| |
| |
| | |
Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a similar case to wanting ot use bind params for limit and
offset. Right now passing a range grows the amount of prepared
statements in an unbounded fashion. We could avoid using prepared
statements in that case, similar to what we do with arrays, but there's
a known number of variants for ranges.
This ends up duplicating some of the logic from Arel for how to handle
potentially infinite ranges, and that behavior may be removed from Arel
in the future.
Fixes #23074
|
| |
| |
| |
| |
| |
| | |
instead of start_at/end_at based on comments
at https://github.com/rails/rails/pull/12257#issuecomment-74688344
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code that set the from clause was removed in
bdc5141652770fd227455681cde1f9899f55b0b9. I did not give any reason for
doing so. My assumption was that I intended to change it to use the
clause objects, but forgot. We appeared to not have test coverage for
this case.
Fixes #22996
|
| |
| |
| |
| |
| |
| |
| |
| | |
When you are using scopes and you chaining these scopes it is hard to
know which are the values that are incompatible. This way you can read
the message and know for which values you need to look for.
[Herminio Torres]
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 5d41cb3bfd6b19833261622ce5d339b1e580bd8b.
This implementation does not properly handle cases involving predicates
which are not associated with a bind param. I have the fix in mind, but
don't have time to implement just yet. It will be more similar to #22823
than not.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While the predicates are an arel equality node where the left side is a
full arel attribute, the binds just have the name of the column and
nothing else. This means that while splitting the predicates can include
the table as a factor, the binds cannot. It's entirely possible that we
might be able to have the bind params carry a bit more information (I
don't believe the name is used for anything but logging), and that is
probably a worthwhile change to make in the future.
However the simplest (and likely slightly faster) solution is to simply
use the indices of the conflicts in both cases. This means that we only
have to compute the collision space once, instead of twice even though
we're doing an additional array iteration. Regardless, this method isn't
a performance hotspot.
Close #22823.
[Ben Woosley & Sean Griffin]
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Refactor `case_{sensitive|insensitive}_comparison`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```
SELECT 1 AS one FROM "topics" WHERE "topics"."title" = 'abc' LIMIT $1 [["LIMIT", 1]]
```
After:
```
SELECT 1 AS one FROM "topics" WHERE "topics"."title" = $1 LIMIT $2 [["title", "abc"], ["LIMIT", 1]]
```
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I realized that `first(2)`, etc. was unnecessarily querying for the
records when they were already preloaded. This was because
`find_nth_with_limit` can not know which `@records` to return because
it conflates the `offset` and `index` into a single variable, while
the `@records` only needs the `index` itself to select the proper
record.
Because `find_nth` and `find_nth_with_limit` are public methods, I
instead introduced a private method `find_nth_with_limit_and_offset`
which is called internally and handles the `loaded?` checking.
Once the `offset` argument is removed from `find_nth`,
`find_nth_with_limit_and_offset` can be collapsed into
`find_nth_with_limit`, with `offset` always equal to `offset_index`.
|
|
|
|
|
|
|
|
| |
All uses of the `offset` are passing `offset_index`. Better to push
down the `offset` consideration into `find_nth`.
This also works toward enabling `find_nth_with_limit` to take
advantage of the `loaded?` state of the relation.
|
|\
| |
| |
| | |
ActiveRecord::Base#find(array) returning result in the same order as the array passed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We know the query will return exactly one row for each entry in the
`ids` array, so we can do all the limit/offset calculations on that
array, in advance.
I also split our new ordered-ids behaviour out of the existing
`find_some` method: especially with this change, the conditionals were
overwhelming the actual logic.
|
| |
| |
| |
| | |
@values hash
|
| |
| |
| |
| | |
.find(array) with offset
|
| |
| |
| |
| | |
the user via :order clause
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```
# before
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This
still causes `String`s to be parsed as if they were in `Time.zone`,
and `Time`s to be converted to `Time.zone`.
To keep the old behavior, you must add the following to your initializer:
config.active_record.time_zone_aware_types = [:datetime]
To silence this deprecation warning, add the following:
config.active_record.time_zone_aware_types << :time
```
```
# after
DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This
still causes `String`s to be parsed as if they were in `Time.zone`,
and `Time`s to be converted to `Time.zone`.
To keep the old behavior, you must add the following to your initializer:
config.active_record.time_zone_aware_types = [:datetime]
To silence this deprecation warning, add the following:
config.active_record.time_zone_aware_types << :time
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 6d5b1fdf55611de2a1071c37544933bb588ae88e.
`eager_load` and `references` can include hashes, which won't match up
with `references`
A test case has been added to demonstrate the problem
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was changed in 421c81b, as `exists?` blows up if you are eager
loading a polymorphic association, as it'll try to construct a join to
that table. The previous change decided to execute a `count` instead,
which wouldn't join.
Of course, the only time we actually need to perform a join on the eager
loaded values (which would perform a left outer join) is if they're
being referenced in the where clause. This doesn't affect inner joins.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We currently generate an unbounded number of prepared statements when
`limit` or `offset` are called with a dynamic argument. This changes
`LIMIT` and `OFFSET` to use bind params, eliminating the problem.
`Type::Value#hash` needed to be implemented, as it turns out we busted
the query cache if the type object used wasn't exactly the same object.
This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`.
Doing this relied on AR internals, and was never officially supported
usage.
Fixes #22250.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some backends allow `LIMIT 1,2` as a shorthand for `LIMIT 1 OFFSET 2`.
Supporting this in Active Record massively complicates using bind
parameters for limit and offset, and it's trivially easy to build an
invalid SQL query by also calling `offset` on the same `Relation`.
This is a niche syntax that is only supported by a few adapters, and can
be trivially worked around by calling offset explicitly.
|
| |
| |
| |
| |
| | |
It appears that I missed this one when I delegated all the non-mutation
array methods that were not on Enumerable
|
| |
| |
| |
| | |
[ci skip]
|
|\ \
| | |
| | | |
Update and fix forbidden attributes test issues caused by AC::Parameters change
|