- 05 4月, 2019 11 次提交
-
-
由 Ryuta Kamizono 提交于
Stash `left_joins` into `joins` to deduplicate redundant LEFT JOIN
-
由 Vipul A M 提交于
fix typo in the guides (use Rails instead of rails) [ci skip]
-
由 Edward Rudd 提交于
-
由 Ryuta Kamizono 提交于
Originally the `JoinDependency` has the deduplication for eager loading (LEFT JOIN). This re-uses that deduplication for `left_joins`. And also, This makes left join order into part of joins, i.e.: Before: ``` association joins -> stash joins (eager loading, etc) -> string joins -> left joins ``` After: ``` association joins -> stash joins (eager loading, left joins, etc) -> string joins ``` Now string joins are able to refer left joins. Fixes #34325. Fixes #34332. Fixes #34536.
-
由 Vipul A M 提交于
Add documentation for 'after_save_commit' [ci skip]
-
由 Sharang Dashputre 提交于
-
由 Rafael França 提交于
Adds 'detach_from' to 'ActiveSupport::Subscriber' to detach a subscriber from a namespace.
-
由 Rafael França 提交于
Fix arity warning for template handlers
-
由 localhostdotdev 提交于
Mainly to help with knowning which template is reponsible for the warning. handler.class # => Class handler.to_s # => Coffee::Rails::TemplateHandler Before: Change: >> Class#call(template) To: >> Class#call(template, source) After: Change: >> Coffee::Rails::TemplateHandler.call(template) To: >> Coffee::Rails::TemplateHandler.call(template, source)
-
由 Ryuta Kamizono 提交于
Follow up of #26764 and #35700. And add test case for #35700.
-
由 Ryuta Kamizono 提交于
Reintroduce support for overriding `has_secure_password` attributes
-
- 04 4月, 2019 29 次提交
-
-
由 Ryuta Kamizono 提交于
``` % be rubocop -a Inspecting 2777 files ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................C.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. Offenses: tools/test_common.rb:1:1: C: [Corrected] Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true. if ENV["BUILDKITE"] ^ 2777 files inspected, 1 offense detected, 1 offense corrected ```
-
由 Kasper Timm Hansen 提交于
Fix deprecation warning about variants and formats
-
由 Prathamesh Sonpatki 提交于
- After https://github.com/rails/rails/pull/35408 and https://github.com/rails/rails/pull/35406, the `formats` and `variants` methods are deprecated in favor of `format` and `variant`.
-
由 Matthew Draper 提交于
Output junit format test report
-
由 Ryuta Kamizono 提交于
Fix `count(:all)` with eager loading and explicit select and order
-
由 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.
-
由 Fumiaki MATSUSHIMA 提交于
-
由 sushant 提交于
-
由 Ryuta Kamizono 提交于
Refactor `Relation#cache_key` is moved from `CollectionCacheKey#collection_cache_key`
-
由 Ryuta Kamizono 提交于
The implementation of `Relation#cache_key` depends on some internal relation methods (e.g. `apply_join_dependency`, `build_subquery`), but somehow that implementation exists on the model class (`collection_cache_key`), it sometimes bothers to me. This refactors that implementation moves to `Relation#cache_key`, then we can avoid `send` to call internal methods.
-
由 Ryuta Kamizono 提交于
Optimizer hints should be applied on Top level query as much as possible
-
由 Rafael França 提交于
Fix partial caching ignore repeated items issue
-
由 Ryuta Kamizono 提交于
I've experienced this issue in our app, some hints only works on Top level query (e.g. `MAX_EXECUTION_TIME`).
-
由 st0012 提交于
This is because we only use hash to maintain the result. So when the key are the same, the result would be skipped. The solution is to maintain an array for tracking every item's position to restructure the result.
-
由 Ryuta Kamizono 提交于
We have `Style/RedundantBegin` cop (#34764) but it could not correct in this case.
-
由 Ryuta Kamizono 提交于
Some tests expects that internal metadata tables exists, and we should not use `create_table` in transactional tests, since DDL in MySQL causes implicit commit. https://travis-ci.org/rails/rails/jobs/515438937#L3829
-
由 Rafael França 提交于
Fix checking for template variants when using the ActionView::FixtureResolver
-
由 Edward Rudd 提交于
-
由 Edward Rudd 提交于
-
由 Ryuta Kamizono 提交于
Also, `reset_column_information` is unnecessary since `reset_table_name` does that too.
-
由 Rafael França 提交于
Deduplicate strings held by the router
-
由 Jean Boussier 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Use `execute_batch2` rather than `execute_batch` to fix performance regression for fixture loading
-
由 Ryuta Kamizono 提交于
d8d6bd5e makes fixture loading to bulk statements by using `execute_batch` for sqlite3 adapter. But `execute_batch` is slower and it caused the performance regression for fixture loading. In sqlite3 1.4.0, it have new batch method `execute_batch2`. I've confirmed `execute_batch2` is extremely faster than `execute_batch`. So I think it is worth to upgrade sqlite3 to 1.4.0 to use that method. Before: ``` % ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids Using sqlite3 Run options: -n test_eager_loading_too_may_ids --seed 35790 # Running: . Finished in 202.437406s, 0.0049 runs/s, 0.0049 assertions/s. 1 runs, 1 assertions, 0 failures, 0 errors, 0 skips ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 142.57s user 60.83s system 98% cpu 3:27.08 total ``` After: ``` % ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids Using sqlite3 Run options: -n test_eager_loading_too_may_ids --seed 16649 # Running: . Finished in 8.471032s, 0.1180 runs/s, 0.1180 assertions/s. 1 runs, 1 assertions, 0 failures, 0 errors, 0 skips ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 10.71s user 1.36s system 95% cpu 12.672 total ```
-
由 Eileen M. Uchitelle 提交于
Make Resolver#find_all_anywhere equivalent to #find_all
-
由 Eileen M. Uchitelle 提交于
Add test that the listen gem is included when RUBY_ENGINE is not 'ruby'
-