| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
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
```
|
| |
|
| |
|
|
|
|
| |
`exists?`
|
|
|
|
|
| |
Pass the id of the object to the method by calling `.id` on the AR
object.
|
| |
|
|
|
|
| |
This will avoid the confusing flunk logic
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When we build a query with an inline value that is a numeric (e.g.
because it's out of range for an int4) PostgreSQL doesn't use an index
on the column, since it's now comparing numerics and not int4s.
This leads to a _very_ slow query.
When we use bound parameters instead of inline values PostgreSQL
raises numeric_value_out_of_range since no automatic coercion happens.
|