| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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`.
|
|
|
|
| |
Fix failing tests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 AR::Relation#last bugs instroduced in 7705fc
|
| |
| |
| |
| | |
instead of loading the relation into memory
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`test_find_with_order_on_included_associations_with_construct_finder_sql_for_association_limiting_and_is_distinct` to NULL-agnostic way
The sort order of NULL depends on the RDBS implementation. This commit
is to fix the test to NULL-agnostic way.
Example:
```
activerecord_unittest=# SELECT DISTINCT "posts"."id", author_addresses_authors.id AS alias_0 FROM "posts" LEFT OUTER JOIN "authors" ON "authors"."id" = "posts"."author_id" LEFT OUTER JOIN "author_addresses" ON "author_addresses"."id" = "authors"."author_address_id" LEFT OUTER JOIN "categorizations" ON "categorizations"."category_id" = "posts"."id" LEFT OUTER JOIN "authors" "authors_posts" ON "authors_posts"."id" = "categorizations"."author_id" LEFT OUTER JOIN "author_addresses" "author_addresses_authors" ON "author_addresses_authors"."id" = "authors_posts"."author_address_id" ORDER BY author_addresses_authors.id DESC;
id | alias_0
----+---------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
1 | 1
(12 rows)
```
```
root@localhost [activerecord_unittest] > SELECT DISTINCT `posts`.`id`, author_addresses_authors.id AS alias_0 FROM `posts` LEFT OUTER JOIN `authors` ON `authors`.`id` = `posts`.`author_id` LEFT OUTER JOIN `author_addresses` ON `author_addresses`.`id` = `authors`.`author_address_id` LEFT OUTER JOIN `categorizations` ON `categorizations`.`category_id` = `posts`.`id` LEFT OUTER JOIN `authors` `authors_posts` ON `authors_posts`.`id` = `categorizations`.`author_id` LEFT OUTER JOIN `author_addresses` `author_addresses_authors` ON `author_addresses_authors`.`id` = `authors_posts`.`author_address_id` ORDER BY author_addresses_authors.id DESC;
+----+---------+
| id | alias_0 |
+----+---------+
| 1 | 1 |
| 3 | NULL |
| 1 | NULL |
| 2 | NULL |
| 4 | NULL |
| 5 | NULL |
| 6 | NULL |
| 7 | NULL |
| 8 | NULL |
| 9 | NULL |
| 10 | NULL |
| 11 | NULL |
+----+---------+
12 rows in set (0.00 sec)
```
|
|\
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| | |
.find(array) with offset
|
| |
| |
| |
| | |
the user via :order clause
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
`replace_named_bind_variables` and `replace_bind_variables` are
definded in `sanitization.rb`, so it is reasonable these tests are
on `sanitize_test.rb`.
|
| |
| |
| |
| |
| |
| |
| | |
In this commit, find_by doesn't cache arguments
so that find_by with association subquery works correctly.
Fixes #20817
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
robertjlooby/fix_overwriting_by_dynamic_finders"
This reverts commit d5ba9a42a6e93b163a49f99d739aa56820e044d0, reversing
changes made to 30c503395bf6bf7db1ec0295bd661ce644628db5.
Reason: This generate the dynalic finders more than one time
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If there is a method defined such as `find_and_do_stuff(id)`, which then
gets called on an association, we will perform statement caching and the
parent ID will not change on subsequent calls.
Fixes #18117
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This ensures that we're handling all forms of nested tables the same way.
We're aware that the `convert_dot_notation_to_hash` method will cause a
performance hit, and we intend to come back to it once we've refactored some of
the surrounding code.
[Melissa Xie & Melanie Gilman]
|
| |
|
|
|
|
|
| |
`Computer` class needs to be require
See #17217 for more details
|
|
|
|
|
| |
We should not behave differently just because a class has a default
scope.
|
|
|
|
|
|
|
|
|
|
|
| |
Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.
Fixes #17380
|
|
|
|
|
|
|
|
|
| |
For now, we will just skip the cache when a non-column key is used in the hash.
If the future, we can probably move some of the logic in PredicateBuilder.expand
up the chain to make caching possible for association queries.
Closes #16903
Fixes #16884
|
|\
| |
| | |
Update RecordNotFound exception cases to include a message with the
|
| |
| |
| |
| | |
Model that the Record was not found in.
|
| |
| |
| |
| |
| |
| |
| |
| | |
`User.where(id: [[1,2],3])` was equal to `User.where(id:[1, 2, 3])`
in Rails 4.1.x but because of some refactoring in Arel this stopped
working in 4.2.0. This fixes it in Rails.
[Dan Olson & Cristian Bica]
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Also duplicated find_by tests from relations_test.rb to finder_test.rb now
that we have a completely different implementation on the class (in core.rb
with AST caching stuff).
* Also removed a (failing) test that used mocks. Now that we have tests for the
behavior, there's no point having another test that tests the implementation
(that it delegates). Further, what the test was implying is nolonger true with
the current implementation, because Class.find_by is a real method now.
|
| |
| |
| |
| | |
Fixes #15821.
|
| |
| |
| |
| | |
Looks like #first wasn't warm enough...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.
As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.
|
|/
|
|
|
|
|
|
| |
```
activerecord/test/cases/adapters/postgresql/range_test.rb:159: warning: (...) interpreted as grouped expression
activerecord/test/cases/finder_test.rb:38: warning: shadowing outer local variable - e
activerecord/test/cases/finder_test.rb:43: warning: shadowing outer local variable - e
```
|
| |
|