| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Follow up of c9e4c848eeeb8999b778fa1ae52185ca5537fffe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This follows up ebc09ed9ad9a04338138739226a1a92c7a2707ee.
We've still experienced a regression for `size` (`count(:all)`) with
eager loading and explicit select and order when upgrading Rails to 5.1.
In that case, the eager loading enforces `distinct` to subselect but
still keep the custom select, it would cause the ORDER BY with DISTINCT
issue.
```
% ARCONN=postgresql bundle exec ruby -w -Itest test/cases/relations_test.rb -n test_size_with_eager_loading_and_custom_select_and_order
Using postgresql
Run options: -n test_size_with_eager_loading_and_custom_select_and_order --seed 8356
# Running:
E
Error:
RelationTest#test_size_with_eager_loading_and_custom_select_and_order:
ActiveRecord::StatementInvalid: PG::InvalidColumnReference: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list
LINE 1: ..." ON "comments"."post_id" = "posts"."id" ORDER BY comments.i...
^
```
As another problem on `distinct` is enforced, the result of `count`
becomes fewer than expected if `select` is given explicitly.
e.g.
```ruby
Post.select(:type).count
# => 11
Post.select(:type).distinct.count
# => 3
```
As long as `distinct` is enforced, we need to care to keep the result of
`count`.
This fixes both the `count` with eager loading problems.
|
|\
| |
| |
| |
| |
| | |
jvillarejo/fix_wrong_size_query_with_distinct_select
Fix different `count` calculation when using `size` with DISTINCT `select`
|
|/
|
|
|
|
|
|
| |
DISTINCT
When using `select` with `'DISTINCT( ... )'` if you use method `size` on a non loaded relation it overrides the column selected by passing `:all` so it returns different value than count.
This fixes #35214
|
|
|
|
| |
Use "support/stubs/strong_parameters" instead.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently custom attributes are always qualified by the table name in
the generated SQL wrongly even if the table doesn't have the named
column, it would cause an invalid SQL error.
Custom attributes should only be qualified if the table has the same
named column.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 89b4612ffc97e6648f5cf807906ae210e05acdda.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
String properly
This reverts 27c6c07 since `arel_attr.to_s` is not right way to avoid
the type error.
That to_s returns `"#<struct Arel::Attributes::Attribute ...>"`, there
is no reason to match the regex to the inspect form.
And also, the regex path is not covered by our test cases. I've tweaked
the regex for redundant part and added assertions for the regex path.
|
| |
|
| |
|
|
|
|
|
| |
Move `ActiveRecord::StatementInvalid` SQL to error property.
Also add bindings as an error property.
|
|
|
|
| |
to speed up pluck
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If `eager_loading` is true, `apply_join_dependency` force applies
LIMIT/OFFSET before JOINs by `limited_ids_for` to keep parent records
count. But for aggregation queries, LIMIT/OFFSET should be applied after
aggregations the same as SQL semantics.
And also, we could not replace SELECT list by `limited_ids_for` when a
query has a GROUP BY clause. It had never been worked since it will
causes generating invalid SQL for MySQL, PostgreSQL, and probably most
backends.
```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_group_by_with_limit
Using postgresql
Run options: -n test_group_by_with_limit --seed 20925
# Running:
E
Error:
CalculationsTest#test_group_by_with_limit:
ActiveRecord::StatementInvalid: PG::GroupingError: ERROR: column "posts.id" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FRO... ^
: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FROM "posts" LEFT OUTER JOIN "comments" ON "comments"."post_id" = "posts"."id" GROUP BY "posts"."type" ORDER BY "posts"."type" ASC LIMIT $1
```
Fixes #8103.
Closes #27249.
|
| |
|
|\
| |
| |
| | |
Active Record distinct & order #count regression
|
|/ |
|
| |
|
|
|
| |
* Add Relation#pick as short-hand for single-value plucks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
driving table
This is a regression caused by 6beb4de.
In PostgreSQL, ORDER BY expressions must appear in SELECT list when
using DISTINCT.
When using `count(:all)` with eager loading, Active Record enforces
DISTINCT to count the driving table records only. 6beb4de was caused the
regression because `count(:all)` with DISTINCT path no longer removes
ORDER BY.
We need to ignore ORDER BY when DISTINCT is enforced, otherwise not
always generated valid SQL for PostgreSQL.
Fixes #31783.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `count(:all)` with `distinct` doesn't work correctly because
SELECT list is always replaced to `*` or primary key in that case even
if having custom SELECT list.
And also, PostgreSQL has a limitation that ORDER BY expressions must
appear in select list for SELECT DISTINCT.
Therefore, we should not replace custom SELECT list when using
`count(:all)` with `distinct`.
Closes #31277.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the fix for the regression of #29848.
In #29848, I've kept existing select list in the subquery for the count
if ORDER BY is given. But it had accidentally affect to GROUP BY
queries also. It should keep the previous behavior in that case.
Fixes #30886.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`to_i` was added for SQLite3 adapter which did not handle number
but sqlite3 gem already supports it then `to_i` is unnecessary.
else condition is kept for adapters which return string,
i.e. mysql(not mysql2) and sqlserver.
Renamed `test_cache_does_not_wrap_string_results_in_arrays`
to `test_cache_does_not_wrap_results_in_arrays` to explain the
current behavior. most of adapters return integer, not only string.
* Refer these commits:
"future proofing the sqlite3 adapter code"
https://github.com/rails/rails/commit/beda2d43d6ac5c3435fc2fba0cbd108c20fe1c67
"Refactor calculation test to remove unneeded SQLite special case."
https://github.com/rails/rails/commit/47d568ed3fc701934ebe80b276f3d8bf6951c93f
"no need to to_i, sqlite does that for us"
https://github.com/rails/rails/commit/6cf44a1bd64ba10497742d70ad78fe68faa16e99
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Since #26972, `ORDER BY` is kept if `LIMIT` is presented for
performance. But in most SQL servers (e.g. PostgreSQL, SQL Server, etc),
`ORDER BY` expressions must appear in select list for `SELECT DISTINCT`.
We should not replace existing select list in that case.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, test fails because the load schema when pluck is executed.
Steps to reproduce:
```
bin/test -a postgresql -w --seed 61689 test/cases/*test.rb -n "/^(?:InheritanceComputeTypeTest#(?:test_inheritance_new_with_subclass_as_default)|CalculationsTest#(?:test_pluck_loaded_relation))$/"
# Running:
.F
Failure:
CalculationsTest#test_pluck_loaded_relation [/home/yaginuma/program/rails/master_y_yagi/rails/activerecord/test/cases/calculations_test.rb:722]:
1 instead of 0 queries were executed.
Queries:
SELECT c.relname FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE n.nspname = ANY (current_schemas(false)) AND c.relname = 'companies' AND c.relkind IN ('r','v','m').
Expected: 0
Actual: 1
bin/test test/cases/calculations_test.rb:7
```
|
|\
| |
| | |
Extract `NumericData` model for tests
|
| |
| |
| |
| | |
Currently `NumericData` model is defined some places.
|
| |
| |
| |
| |
| |
| |
| |
| | |
in `ActiveRecord::Calculations`
`select`, `count`, and `sum` in `Relation` are also `Enumerable` method
that can be passed block. `select` with block already doesn't take
arguments since 4fc3366. This is follow up of that.
|
| |
| |
| |
| |
| |
| | |
Support for using `SELECT` column or expression aliases in the `HAVING`
clause isn't part of the SQL standard so it's better to whitelist the
test for adapters where we know it works and skip it on others.
|
| |
| |
| |
| | |
Follow up #28183
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_apply_distinct_in_count
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/core_ext/enumerable.rb:20: warning: method redefined; discarding old sum
Using postgresql
Run options: -n test_apply_distinct_in_count --seed 27731
F
Finished in 0.163682s, 6.1094 runs/s, 30.5470 assertions/s.
1) Failure:
CalculationsTest#test_apply_distinct_in_count [test/cases/calculations_test.rb:238]:
Expected /\ASELECT(?! DISTINCT) COUNT\(DISTINCT\b/ to match "SHOW max_identifier_length".
1 runs, 5 assertions, 1 failures, 0 errors, 0 skips
```
https://travis-ci.org/rails/rails/jobs/205493811#L1933
https://travis-ci.org/rails/rails/jobs/205496299#L1562
https://travis-ci.org/rails/rails/jobs/205514765#L1562
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a grouped calculation contains a having clause that references a
selected value, we need to include that selected value in the query.
Postgres doesn't support referencing a selected value in a having
clause, but other databases do; we can skip the test on the pg adapter
but run it for the others.
This was fixed before in 9a298a162c16e019fe6971e563e7f4916e86ced6, but
the test coverage was lost in 5a05207d99b7e2678f9b42db2d9ffc21ec2c8c3b.
The fix regressed in 6311975fb3c02f50730fd1e11b8dba8dd9c05306 and was
removed in 97d46c17ea9113b0ce970167f5208c8d9170915c.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`DISTINCT` clause is applied inside aggregate function by
`operation_over_aggregate_column` if needed. Unneeded outside aggregate
function.
```ruby
# Before
author.unique_categorized_posts.count
# => SELECT DISTINCT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ? [["author_id", 2]]
# After
author.unique_categorized_posts.count
# => SELECT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ? [["author_id", 2]]
```
Closes #27615
|
| |
| |
| |
| | |
This reverts commit 28977f1fa3d7b15c1608174a165e60b71ddf3995.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If select clause is specified and last column has a column alias,
additional column alias causes a statement invalid.
Add test coverage for counting a single column with NULL values.
Fixes #27676, #27682, and #27705.
|
| |
| |
| |
| | |
Refer a similar pull request #26370
|