1. 18 1月, 2015 1 次提交
  2. 14 1月, 2015 1 次提交
  3. 12 1月, 2015 1 次提交
  4. 10 1月, 2015 1 次提交
  5. 09 1月, 2015 2 次提交
  6. 06 1月, 2015 1 次提交
  7. 05 1月, 2015 1 次提交
  8. 04 1月, 2015 7 次提交
  9. 03 1月, 2015 3 次提交
    • P
    • C
      Add config to halt callback chain on return false · 9c65c539
      claudiob 提交于
      This stems from [a comment](rails#17227 (comment)) by @dhh.
      In summary:
      
      * New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
      * Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.
      
      For this purpose, this commit introduces a Rails configuration option:
      
      ```ruby
      config.active_support.halt_callback_chains_on_return_false
      ```
      
      For new Rails 5.0 apps, this option will be set to `false` by a new initializer
      `config/initializers/callback_terminator.rb`:
      
      ```ruby
      Rails.application.config.active_support.halt_callback_chains_on_return_false = false
      ```
      
      For existing apps ported to Rails 5.0, the initializers above will not exist.
      Even running `rake rails:update` will not create this initializer.
      
      Since the default value of `halt_callback_chains_on_return_false` is set to
      `true`, these apps will still accept `return true` as a way to halt callback
      chains, displaying a deprecation warning.
      
      Developers will be able to switch to the new behavior (and stop the warning)
      by manually adding the line above to their `config/application.rb`.
      
      A gist with the suggested release notes to add to Rails 5.0 after this
      commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931
      9c65c539
    • C
      Loosen test about order of initializers · 93dd5028
      claudiob 提交于
      This commit modifies the code (but not the purpose) of a test that checks that
      
      > initializers are executed after application configuration initializers
      
      Currently the test hard-codes the *exact* initializers that are expected to
      occur before a custom one. This can cause the test to fail even if the
      expectation still passes.
      
      This commit loosens the test by simply checking that, in the array of
      initializers, the custom initializers (called `dummy_initializer` in the
      example) is executed after the last occurrence of `load_config_initializers`.
      93dd5028
  10. 02 1月, 2015 5 次提交
  11. 30 12月, 2014 1 次提交
  12. 27 12月, 2014 1 次提交
  13. 23 12月, 2014 4 次提交
    • S
      Add test missed by a03ea684 · b7d7e0b1
      Sean Griffin 提交于
      b7d7e0b1
    • S
      Use the new `foreign_key` option on `references` in generators · a03ea684
      Sean Griffin 提交于
      Changes `rails g model Post user:references` from
      
          def change
            create_table :posts do |t|
              t.references :user, index: true
            end
      
            add_foreign_key :posts, :users
          end
      
      to
      
          def change
            create_table :posts do |t|
              t.references :user, index: true, foreign_key: true
            end
          end
      
      Changes `rails g migration add_user_to_posts user:references` from
      
          def change
            add_reference :posts, :users, index: true
            add_foreign_key :posts, :users
          end
      
      to
      
          def change
            add_reference :posts, :users, index: true, foreign_key: true
          end
      a03ea684
    • S
      Skip byebug on all non-MRI rubies, fix tests · 9fff631a
      Sean Griffin 提交于
      The changes in #18149 added tests for the app generator, but only fixed
      it for the plugin generator (I should have let CI finish though I think
      it would have failed as an allowed failure).
      9fff631a
    • A
      Only add debugger/byebug if on MRI · 0bb73f03
      Arthur Neves 提交于
      0bb73f03
  14. 20 12月, 2014 1 次提交
  15. 18 12月, 2014 1 次提交
    • Y
      `db:structure:load` and `db:schema:load` no longer purge the database. · 36ce0c2c
      Yves Senn 提交于
      Closes #17945
      
      `db:test:prepare` still purges the database to always keep the test
      database in a consistent state.
      
      This patch introduces new problems with `db:schema:load`. Prior
      to the introduction of foreign-keys, we could run this file against
      a non-empty database. Since every `create_table` containted the
      `force: true` option, this would recreate tables when loading the schema.
      
      However with foreign-keys in place, `force: true` wont work anymore and
      the task will crash.
      
      /cc @schneems
      36ce0c2c
  16. 14 12月, 2014 1 次提交
  17. 07 12月, 2014 1 次提交
  18. 03 12月, 2014 3 次提交
  19. 02 12月, 2014 2 次提交
  20. 29 11月, 2014 2 次提交