- 04 4月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
This follows up ebc09ed9. 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.
-
- 26 2月, 2019 1 次提交
-
-
由 jvillarejo 提交于
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
-
- 24 2月, 2019 2 次提交
-
-
由 Ryuta Kamizono 提交于
Use "support/stubs/strong_parameters" instead.
-
由 Ryuta Kamizono 提交于
-
- 13 2月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 18 1月, 2019 3 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
由 Rafael Mendonça França 提交于
-
由 Rafael Mendonça França 提交于
-
- 04 1月, 2019 1 次提交
-
-
由 Alberto Almagro 提交于
This reverts commit 89b4612f.
-
- 02 1月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
This reverts 27c6c071 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.
-
- 06 12月, 2018 1 次提交
-
-
由 Gannon McGibbon 提交于
-
- 03 12月, 2018 1 次提交
-
-
由 Abdallah Samman 提交于
-
- 23 11月, 2018 1 次提交
-
-
由 Gannon McGibbon 提交于
Move `ActiveRecord::StatementInvalid` SQL to error property. Also add bindings as an error property.
-
- 19 6月, 2018 1 次提交
-
-
由 Lachlan Sylvester 提交于
-
- 07 6月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 09 3月, 2018 1 次提交
-
-
由 Yuji Hanamura 提交于
-
- 26 2月, 2018 1 次提交
-
-
由 Max Schwenk 提交于
-
- 13 2月, 2018 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 10 2月, 2018 1 次提交
-
-
由 David Heinemeier Hansson 提交于
* Add Relation#pick as short-hand for single-value plucks
-
- 25 1月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
This is a regression caused by 6beb4de7. 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. 6beb4de7 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.
-
- 07 1月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 20 12月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 09 11月, 2017 2 次提交
- 14 10月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 01 9月, 2017 1 次提交
-
-
由 Yasuo Honda 提交于
`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
-
- 22 7月, 2017 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
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.
-
- 20 7月, 2017 1 次提交
-
-
由 Kir Shatrov 提交于
-
- 06 7月, 2017 1 次提交
-
-
由 Eugene Kenny 提交于
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.
-
- 02 7月, 2017 1 次提交
-
-
由 Matthew Draper 提交于
This reverts commit 3420a145, reversing changes made to afb66a5a.
-
- 01 7月, 2017 1 次提交
-
-
由 Kir Shatrov 提交于
-
- 06 6月, 2017 2 次提交
-
-
由 Koichi ITO 提交于
-
由 yuuji.yaginuma 提交于
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 ```
-
- 29 5月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
Deprecate passing arguments and block at the same time to `count` and `sum` 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 4fc3366d. This is follow up of that.
-
- 01 3月, 2017 1 次提交
-
-
由 Andrew White 提交于
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.
-
- 28 2月, 2017 1 次提交
-
-
由 Yasuo Honda 提交于
Follow up #28183
-
- 27 2月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
``` % 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
-
- 26 2月, 2017 2 次提交
-
-
由 Eugene Kenny 提交于
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 9a298a16, but the test coverage was lost in 5a05207d. The fix regressed in 6311975f and was removed in 97d46c17.
-
由 Ryuta Kamizono 提交于
`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
-