- 04 4月, 2019 25 次提交
-
-
由 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.
-
由 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'
-
由 Tim Wade 提交于
* Add example for has_many :through source/source_type * Add example for has_one :through source/source_type
-
由 John Hawthorn 提交于
Previously, when using `render file:`, it was possible to render files not only at an absolute path or relative to the current directory, but relative to ANY view paths. This was probably done for absolutely maximum compatibility when addressing CVE-2016-0752, but I think is unlikely to be used in practice. Tihs commit removes the ability to `render file:` with a path relative to a non-fallback view path. Make FallbackResolver.new private To ensure nobody is making FallbackResolvers other than "/" and "". Make reject_files_external_... no-op for fallbacks Because there are only two values used for path: "" and "/", and File.join("", "") == File.join("/", "") == "/", this method was only testing that the absolute paths started at "/" (which of course all do). This commit doesn't change any behaviour, but it makes it explicit that the FallbackFileSystemResolver works this way. Remove outside_app_allowed argument Deprecate find_all_anywhere This is now equivalent to find_all Remove outside_app argument Deprecate find_file for find Both LookupContext#find_file and PathSet#find_file are now equivalent to their respective #find methods.
-
- 03 4月, 2019 15 次提交
-
-
由 Eileen M. Uchitelle 提交于
Cache database version in schema cache
-
由 Ali Ibrahim 提交于
* The database version will get cached in the schema cache file during the schema cache dump. When the database version check happens, the version will be pulled from the schema cache and thus avoid querying the database for the version. * If the schema cache file doesn't exist, we'll query the database for the version and cache it on the schema cache object. * To facilitate this change, all connection adapters now implement #get_database_version and #database_version. #database_version returns the value from the schema cache. * To take advantage of the cached database version, the database version check will now happen after the schema cache is set on the connection in the connection pool.
-
由 Benoit Daloze 提交于
* The fix is already in master since https://github.com/rails/rails/pull/34243 * See https://github.com/rails/rails/pull/35482 for the fix in Rails 5.2
-
由 Kasper Timm Hansen 提交于
-
由 Ryuta Kamizono 提交于
Add rake db:prepare entry to the CHANGELOG.md [ci skip]
-
由 Roberto Miranda 提交于
-
由 Ryuta Kamizono 提交于
`original_app_name` is used to show error message if giving app name is invalid, it should be shown raw app name.
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
[ci skip] Doc for shallow: false options should use <tt> for better readability.
-
由 Abhay Nikam 提交于
-
由 Ryuta Kamizono 提交于
`@changed_attributes` is no longer used since #30985.
-
由 Ryuta Kamizono 提交于
* s/Postgres/PostgreSQL/ * s/MYSQL/MySQL/, s/Mysql/MySQL/ * s/Sqlite/SQLite/ Replaced all newly added them after 6089b314.
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Fixed description of the `cache_key_with_version` method [skip ci]
-