- 13 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
This is the opposite direction of #39039. #39111 fixes `minimum` and `maximum` on date columns with type casting by column type on the database. But column type has no information for time zone aware attributes, it means that attribute type should always be precedence over column type. I've realized that fact in the related issue report #39248. I've reverted the expectation of #39039, to make time zone aware attributes works.
-
- 07 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
Actually that result is odd and hard to predictable result to me, but we should not change the public behavior without deprecation cycle. I had not intended to break any apps, so I've restored the behavior. Fixes #39171.
-
- 02 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
I supposed all aggregation functions will return numeric result in #39039, but that assumption was incorrect for `minimum` and `maximum`, if an aggregated column is non numeric type. I've restored type casting aggregated result for `minimum` and `maximum`. Fixes #39110.
-
- 01 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
`column_types` is empty except PostgreSQL adapter, and `attribute_types.each_key { |k| column_types.delete k }` is also empty even if PostgreSQL adapter almost all case, so that code is quite useless. This improves performance for `find_by_sql` to avoid that useless loop as much as possible. ```ruby ActiveRecord::Schema.define do create_table :active_storage_blobs do |t| t.string :key, null: false t.string :filename, null: false t.string :content_type t.text :metadata t.string :service_name, null: false t.bigint :byte_size, null: false t.string :checksum, null: false t.datetime :created_at, null: false t.index [ :key ], unique: true end end class ActiveStorageBlob < ActiveRecord::Base end Benchmark.ips do |x| x.report("find_by") { ActiveStorageBlob.find_by(id: 1) } end ``` Before: ``` Warming up -------------------------------------- find_by 1.256k i/100ms Calculating ------------------------------------- find_by 12.595k (± 3.4%) i/s - 64.056k in 5.091599s ``` After: ``` Warming up -------------------------------------- find_by 1.341k i/100ms Calculating ------------------------------------- find_by 13.170k (± 3.5%) i/s - 67.050k in 5.097439s ``` To avoid column types loop for PostgreSQL adapter, this skips returning additional column types if a column has already been type casted by pg decoders. Fortunately this fixes #36186 partly for common types.
-
- 25 4月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
Currently, `count` and `average` always returns numeric value, but `sum`, `maximum`, and `minimum` not always return numeric value if aggregated on custom attribute type. I think that inconsistent behavior is surprising: ```ruby # All adapters except postgresql adapter are affected # by custom type casting. Book.group(:status).sum(:status) # => { "proposed" => "proposed", "published" => nil } ``` That is caused by fallback looking up cast type to `type_for(column)`. Now all supported adapters can return numeric value without that fallback, so I think we can remove that, it will also fix aggregate functions to return numeric value consistently.
-
- 24 4月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
mysql2 gem have type casting mechanism from raw payload to Ruby primitive object.
-
- 12 4月, 2020 1 次提交
-
-
由 Jonathan Hefner 提交于
Example failure: https://buildkite.com/rails/rails/builds/68187#333e3624-ac0d-4b23-95b9-f068d9901093/1016-1028 These tests expect the 2nd Account fixture (with a NULL `firm_id`) to be in the first four rows of the result set, but that behavior is not guaranteed without an `order`.
-
- 19 3月, 2020 1 次提交
-
-
由 Eugene Kenny 提交于
When called on a loaded relation, `pick` will now use the existing results instead of making another query, just like `pluck` does.
-
- 27 1月, 2020 2 次提交
-
-
由 Ryuta Kamizono 提交于
Like as before Rails 6.0. Closes #38309.
-
由 Ryuta Kamizono 提交于
Follow up #37266.
-
- 14 1月, 2020 1 次提交
-
- 11 10月, 2019 1 次提交
-
- 08 8月, 2019 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
- 07 8月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
c9e4c848 has one performance optimization for `aggregate_alias` to early returning by `aggregate_alias.match?(/\A\w+\z/)`, but it is caused a regression that failing deduplication for non word chars #36867. I've quited the optimization and add a test to prevent a future regression. Fixes #36867.
-
- 02 8月, 2019 1 次提交
-
-
由 Godfrey Chan 提交于
These tests verifies that aggregates like `AVG` can be selected as "virtual attributes" on Active Record models and have the correct column type.
-
- 08 7月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
It appears that Oracle does not allow using aliases in GROUP BY clause unlike ORDER BY clause. Fixes #36613.
-
- 17 6月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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 311f0011). 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 311f0011) to fix the regression #36022. Fixes #36022.
-
- 11 6月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 02 6月, 2019 1 次提交
-
-
由 Yasuo Honda 提交于
```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"]] ```
-
- 22 5月, 2019 2 次提交
-
-
由 Ryuta Kamizono 提交于
And no longer need to except SCHEMA SQLs manually since 0810c076.
-
由 Ryuta Kamizono 提交于
This reverts commit a1ee4a9f. Even if a1ee4a9f 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 a1ee4a9f which filling schema cache before `assert_no_queries`, and replace `assert_no_queries` to `assert_queries(0)`.
-
- 08 4月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
Follow up of c9e4c848.
-
- 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 提交于
-