| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
joined table
The error happens in PostgreSQL when using `relation.exists?` with
`distinct`, `offset` and `order` for joined table.
However, the error does not happen if either `distinct` or `offset` is
removed. This behavior is confusing.
Fixes #36632
|
|
|
|
|
| |
It is for agnostic test case, since quoted table name may include `.`
for all adapters, and `[` / `]` for sqlserver adapter.
|
|
|
|
|
|
| |
Before 1340498d2, `order` with no-op value (e.g. `nil`, `""`) had broken
the contract of ordinal methods, which returns a result deterministic
ordered.
|
|
|
|
|
|
|
| |
An `author` has a lots of `posts` in the fixtures, so the result of
`author.post` and finding a `post` by `author_id` is non-deterministic.
https://travis-ci.org/rails/rails/jobs/504332292#L1202-L1208
|
|
|
|
| |
Use "support/stubs/strong_parameters" instead.
|
|
|
|
|
|
|
|
|
|
|
| |
The `distinct` affects (reduces) rows of the result, so it is important
part when both `distinct` and `offset` are given.
Replacing SELECT clause to `1 AS one` and removing `distinct` and
`order` is just optimization for the `exists?`, we should not apply the
optimization for that case.
Fixes #35191.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently several queries cannot return correct result due to incorrect
`RangeError` handling.
First example:
```ruby
assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists?
assert_equal true, Topic.where.not(id: 9223372036854775808).exists?
```
The first example is obviously to be true, but currently it returns
false.
Second example:
```ruby
assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1)
```
The second example also should return the object, but currently it
raises `RecordNotFound`.
It can be seen from the examples, the queries including large number
assuming empty result is not always correct.
Therefore, This change handles `RangeError` to generate executable SQL
instead of raising `RangeError` to users to always return correct
result. By this change, it is no longer raised `RangeError` to users.
|
|\
| |
| |
| |
| | |
dylanahsmith/better-composed-of-single-field-query
activerecord: Use a simpler query condition for aggregates with one mapping
|
| | |
|
|/
|
|
|
| |
Clarify changelog entry
Related to #34891
|
|
|
|
|
| |
Allow `ActionController::Params` as argument of
`ActiveRecord::Base#exists?`
|
|
|
|
|
|
| |
since Ruby 2.5
https://bugs.ruby-lang.org/issues/14133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling ordered finder methods such as +first+ or +last+ without an
explicit order clause, ActiveRecord sorts records by primary key. This
can result in unpredictable and surprising behaviour when the primary
key is not an auto-incrementing integer, for example when it's a UUID.
This change makes it possible to override the column used for implicit
ordering such that +first+ and +last+ will return more predictable
results. For Example:
class Project < ActiveRecord::Base
self.implicit_order_column = "created_at"
end
|
|
|
|
|
|
| |
Any type can be a primary key, so blank string is also valid value.
Closes #26356.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At https://github.com/rails/rails/commit/fc0e3354af7e7878bdd905a95ce4c1491113af9a,
```rb
relation = relation.where(conditions)
```
was rewritten to:
```rb
relation.where!(condition)
```
This change accidentally changed the result of `Topic.exists?({})` from true to false.
To fix this regression, first I moved the blank check logic (`opts.blank?`) from `#where` to `#where!`,
because I thought `#where!` should be identical to `#where`, except that instead of returning a new relation,
it adds the condition to the existing relation.
But on second thought after some discussion on https://github.com/rails/rails/pull/34329,
I started to think that just fixing `#construct_relation_for_exists` is more preferable
than changing `#where` and `#where!`.
|
|
|
|
|
|
| |
When you pass an empty array to find we know we shoudl return an empty
array but it is surprising that we are returning the original empty
array instead of a new one.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d162188dd662a7d9f62ba8431474f50bc35e3e93, reversing
changes made to 3576782888c307e3e192c44e332b957cd1174128.
Reason: #24131 conflicts the #5153's default order contract, it means
that existing apps would be broken by that change.
We don't want to break existing apps without a deprecation cycle.
|
| |
|
| |
|
| |
|
|
|
|
| |
https://travis-ci.org/rails/rails/jobs/375326992#L1160-L1166
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
|
| |
Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary
key values even if `ORDER BY` columns include other table's primary key.
Fixes #28364.
|
|
|
|
|
| |
* Add test case for open-ended range.
* Add test case for numeric range for string column.
|
|
|
|
|
|
|
|
|
| |
Follow up of #31724.
If `composed_of` objects have multiple mappings, array predicate handler
can not correctly handle the expanded condition.
We need to handle it like polymorphic association objects.
|
|\
| |
| |
| | |
Fix not expanded problem when passing an Array object as argument to the where method using composed_of column.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
where method using composed_of column.
Fixes #31723
```
david_balance = customers(:david).balance
Customer.where(balance: [david_balance]).to_sql
# Before: WHERE `customers`.`balance` = NULL
# After : WHERE `customers`.`balance` = 50
```
|
|/ |
|
|
|
|
|
|
| |
`relation.exists?` just wants to know if there is a result or not, does
not need the exact records matched. Therefore, an intermediate SELECT
query for eager loading is not necessary.
|
| |
|
|
|
|
|
|
| |
Currently `last` with `offset` behaves incorrectly because `offset` can
not be reversed like `limit`. Therefore, `offset` should also be handled
like `limit`.
|
|
|
|
| |
actual result
|
|
|
|
| |
Follow up of #31432.
|
|
|
|
| |
Follow up of #31390.
|
|
|
|
|
|
|
|
|
|
|
| |
rails/kamipo/ordinal_methods_should_respect_loaded_records"
This reverts commit 0f79ab91150b4cdb6c018530978a3395962c7a02, reversing
changes made to d575f7f2e737739302a0e8210d01c10f5d4e2c35.
This PR philosophically conflicts with #30800 and Matthew thinks we
should hold off merging this until we find concensus. Reverting since
we're about to cut a release for 5.2.
|
|\
| |
| | |
Provide arguments to RecordNotFound
|
| | |
|
|\ \
| |/
|/|
| |
| | |
rails/kamipo/ordinal_methods_should_respect_loaded_records
Ordinal methods should respect loaded records
|
| |
| |
| |
| |
| |
| | |
We should reset partially loaded `@offsets` cache when latest records
has loaded because the cache has been staled and it may not be
consistent with latest records.
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
test cases
|
|
|
|
|
| |
`relation.exists?` should reference correct aliases while joining tables
of has_many through associations.
|
|\
| |
| | |
Return Not found Ids in ActiveRecord::NotFound
|
| |
| |
| |
| |
| | |
This builds on top of 15e2da656f41af0124f7577858536f3b65462ad5.
now it also returns exact Ids which were not found which will be debugging simple.
|
|\ \
| |/
|/| |
Fix `find_by` with range conditions
|
| |
| |
| |
| |
| | |
`StatementCache` doesn't support range conditions. So we need to through
the args to `FinderMethods#find_by` if range value is passed.
|