1. 04 4月, 2019 5 次提交
    • R
      Use `execute_batch2` rather than `execute_batch` to fix performance regression for fixture loading · 0908184e
      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
      ```
      0908184e
    • E
      Merge pull request #35825 from jhawthorn/always_filter_view_paths · d39b2b68
      Eileen M. Uchitelle 提交于
      Make Resolver#find_all_anywhere equivalent to #find_all
      d39b2b68
    • E
      Merge pull request #35843 from eregon/fix-gem-listen-in-gemfile-master · f960920a
      Eileen M. Uchitelle 提交于
      Add test that the listen gem is included when RUBY_ENGINE is not 'ruby'
      f960920a
    • T
      [skip ci] Add examples for has_{one,many} :through :source and :source_type (#35612) · af56c5c1
      Tim Wade 提交于
      * Add example for has_many :through source/source_type
      
      * Add example for has_one :through source/source_type
      af56c5c1
    • J
      Always reject files external to app · eb52904e
      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.
      eb52904e
  2. 03 4月, 2019 27 次提交
  3. 02 4月, 2019 8 次提交