aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/calculations_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add tests for selecting aggregatesGodfrey Chan2019-08-011-0/+84
| | | | | | These tests verifies that aggregates like `AVG` can be selected as "virtual attributes" on Active Record models and have the correct column type.
* Do not use aliases in GROUP BY clauseRyuta Kamizono2019-07-081-0/+7
| | | | | | | It appears that Oracle does not allow using aliases in GROUP BY clause unlike ORDER BY clause. Fixes #36613.
* PostgreSQL: Fix GROUP BY with ORDER BY virtual count attributeRyuta Kamizono2019-06-171-0/+6
| | | | | | | | | | | | | GROUP BY with virtual count attribute is invalid for almost all databases, but it is valid for PostgreSQL, and it had worked until Rails 5.2.2, so it is a regression for Rails 5.2.3 (caused by 311f001). I can't find perfectly solution for fixing this for now, but I would not like to break existing apps, so I decided to allow referencing virtual count attribute in ORDER BY clause when GROUP BY aggrigation (it partly revert the effect of 311f001) to fix the regression #36022. Fixes #36022.
* All modern adapters returns a numeric value as the result of numeric calculationRyuta Kamizono2019-06-111-5/+1
|
* Address test_pluck_columns_with_same_name failure due to nondeterministic ↵Yasuo Honda2019-06-021-1/+1
| | | | | | | | | | | | | | | | sort order ```ruby $ bundle exec rake test_postgresql ... snip ... Failure: CalculationsTest#test_pluck_columns_with_same_name [/home/yahonda/git/rails/activerecord/test/cases/calculations_test.rb:842]: --- expected +++ actual @@ -1 +1 @@ -[["The First Topic", "The Second Topic of the day"], ["The Third Topic of the day", "The Fourth Topic of the day"]] +[["The Third Topic of the day", "The Fourth Topic of the day"], ["The First Topic", "The Second Topic of the day"]] ```
* Use `capture_sql` instead of `assert_sql` with no patternRyuta Kamizono2019-05-221-9/+6
| | | | And no longer need to except SCHEMA SQLs manually since 0810c07.
* Give up filling schema cache before `assert_no_queries`Ryuta Kamizono2019-05-221-6/+3
| | | | | | | | | | | | | | | | | This reverts commit a1ee4a9ff9d4a3cb255365310ead0dc7b739c6be. Even if a1ee4a9 is applied, CI is still flakiness. https://buildkite.com/rails/rails/builds/61252#2c090afa-aa84-4a2b-8b81-9f09219222c6/994-1005 https://buildkite.com/rails/rails/builds/61252#2e55bf83-1bde-44a2-a4f1-b5c3f6820fb4/929-938 Failing tests by whether schema cache is filled or not, it actually means that whether SCHEMA SQLs are executed or not is not target for the tests. So I've reverted commit a1ee4a9 which filling schema cache before `assert_no_queries`, and replace `assert_no_queries` to `assert_queries(0)`.
* Fix GROUP BY with calculate longer name field to respect `table_alias_length`Ryuta Kamizono2019-04-081-0/+11
| | | | Follow up of c9e4c848eeeb8999b778fa1ae52185ca5537fffe.
* Fix `count(:all)` with eager loading and explicit select and orderRyuta Kamizono2019-04-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #35361 from ↵Ryuta Kamizono2019-02-271-0/+18
|\ | | | | | | | | | | jvillarejo/fix_wrong_size_query_with_distinct_select Fix different `count` calculation when using `size` with DISTINCT `select`
| * fixes different `count` calculation when using `size` manual `select` with ↵jvillarejo2019-02-261-0/+18
|/ | | | | | | | 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
* Remove duplicated protected params definitionsRyuta Kamizono2019-02-241-20/+2
| | | | Use "support/stubs/strong_parameters" instead.
* More exercise tests for distinct count with group byRyuta Kamizono2019-02-241-2/+16
|
* Fix `pluck` and `select` with custom attributesRyuta Kamizono2019-02-131-2/+3
| | | | | | | | | 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.
* All of queries should return correct result even if including large numberRyuta Kamizono2019-01-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Do not allow passing the column name to `sum` when a block is passedRafael Mendonça França2019-01-171-3/+3
|
* Do not allow passing the column name to `count` when a block is passedRafael Mendonça França2019-01-171-3/+3
|
* Revert "Fix NumericData.average test on ruby 2.6"Alberto Almagro2019-01-041-6/+2
| | | | This reverts commit 89b4612ffc97e6648f5cf807906ae210e05acdda.
* Fix TypeError: no implicit conversion of Arel::Attributes::Attribute into ↵Ryuta Kamizono2019-01-021-0/+2
| | | | | | | | | | | | | 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.
* Fix join table column quoting with SQLite.Gannon McGibbon2018-12-051-0/+4
|
* Fix NumericData.average test on ruby 2.6Abdallah Samman2018-12-031-2/+6
|
* Redact SQL in errorsGannon McGibbon2018-11-221-2/+2
| | | | | Move `ActiveRecord::StatementInvalid` SQL to error property. Also add bindings as an error property.
* Avoid creating temporary arrays in ActiveRecord::Result#cast_values in order ↵Lachlan Sylvester2018-06-191-0/+12
| | | | to speed up pluck
* Fix GROUP BY queries to apply LIMIT/OFFSET after aggregationsRyuta Kamizono2018-06-071-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add `delegate :pick, to: :all`Yuji Hanamura2018-03-091-0/+5
|
* Merge pull request #32005 from maschwenk/ar-distinct-order-count-regressionRyuta Kamizono2018-02-271-0/+6
|\ | | | | | | Active Record distinct & order #count regression
| * Distinct with order #count regressionMax Schwenk2018-02-251-0/+8
|/
* Add test to make sure pick works in a NullRelationRafael Mendonça França2018-02-121-0/+2
|
* Add Relation#pick as short-hand for single-value plucks (#31941)David Heinemeier Hansson2018-02-091-0/+10
| | | * Add Relation#pick as short-hand for single-value plucks
* Fix `count(:all)` with eager loading and having an order other than the ↵Ryuta Kamizono2018-01-251-1/+7
| | | | | | | | | | | | | | | | | | | 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.
* Fix `pluck` with eager loading to respect `offset`Ryuta Kamizono2018-01-071-0/+5
|
* Fix `count(:all)` to correctly work `distinct` with custom SELECT listRyuta Kamizono2017-12-201-0/+6
| | | | | | | | | | | | | | 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.
* try using regexesBen Toews2017-11-091-7/+7
|
* allow Arel.sql() for pluckBen Toews2017-11-091-12/+12
|
* Fix `COUNT(DISTINCT ...)` for `GROUP BY` with `ORDER BY` and `LIMIT`Ryuta Kamizono2017-10-141-0/+4
| | | | | | | | | | 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.
* sqlite3 adapter returns integer value which used to be stringYasuo Honda2017-09-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | `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
* Merge remote-tracking branch 'origin/master' into unlock-minitestRafael Mendonça França2017-08-011-0/+26
|\
| * Should keep the table name qualified `*` for distinct subqueryRyuta Kamizono2017-07-221-0/+12
| |
| * Fix `COUNT(DISTINCT ...)` with `ORDER BY` and `LIMIT`Ryuta Kamizono2017-07-221-0/+12
| | | | | | | | | | | | | | 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.
| * Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
| |
* | Merge branch 'master' into unlock-minitestKasper Timm Hansen2017-07-151-2/+47
|\|
| * Skip query cache for in_batches and friendsEugene Kenny2017-07-061-0/+42
| | | | | | | | | | | | | | | | | | | | | | 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.
| * Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | | | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
| * Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
| |
| * Fix `test_pluck_without_column_names` when using OracleKoichi ITO2017-06-061-2/+5
| |
* | Load schema before assertionyuuji.yaginuma2017-06-061-0/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* Merge pull request #26634 from kamipo/extract_numeric_dataRafael França2017-05-311-8/+1
|\ | | | | Extract `NumericData` model for tests
| * Extract `NumericData` model for testsRyuta Kamizono2016-09-271-8/+1
| | | | | | | | Currently `NumericData` model is defined some places.
* | Deprecate passing arguments and block at the same time to `count` and `sum` ↵Ryuta Kamizono2017-05-291-0/+12
| | | | | | | | | | | | | | | | 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.
* | Whitelist adapters that support aliases in `HAVING` clauseAndrew White2017-03-011-1/+1
| | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 13:32:27 +0000