| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|