diff options
| -rw-r--r-- | activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb | 10 | ||||
| -rw-r--r-- | guides/source/testing.md | 22 | ||||
| -rw-r--r-- | guides/source/upgrading_ruby_on_rails.md | 16 | ||||
| -rw-r--r-- | railties/lib/rails/application.rb | 4 | ||||
| -rw-r--r-- | railties/lib/rails/engine.rb | 8 |
5 files changed, 41 insertions, 19 deletions
diff --git a/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb b/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb index 3b1e321f4b..42ad285340 100644 --- a/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb +++ b/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb @@ -201,16 +201,14 @@ module ActiveRecord # isolation level. However, support is disabled for MySQL versions below 5, # because they are affected by a bug[http://bugs.mysql.com/bug.php?id=39170] # which means the isolation level gets persisted outside the transaction. - def transaction(options = {}) - options.assert_valid_keys :requires_new, :joinable, :isolation - - if !options[:requires_new] && current_transaction.joinable? - if options[:isolation] + def transaction(requires_new: nil, isolation: nil, joinable: true) + if !requires_new && current_transaction.joinable? + if isolation raise ActiveRecord::TransactionIsolationError, "cannot set isolation when joining a transaction" end yield else - transaction_manager.within_new_transaction(options) { yield } + transaction_manager.within_new_transaction(isolation: isolation, joinable: joinable) { yield } end rescue ActiveRecord::Rollback # rollbacks are silently swallowed diff --git a/guides/source/testing.md b/guides/source/testing.md index 7345c7f522..625f366db1 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -120,9 +120,9 @@ user_<%= n %>: Rails by default automatically loads all fixtures from the `test/fixtures` directory for your models and controllers test. Loading involves three steps: -* Remove any existing data from the table corresponding to the fixture -* Load the fixture data into the table -* Dump the fixture data into a method in case you want to access it directly +1. Remove any existing data from the table corresponding to the fixture +2. Load the fixture data into the table +3. Dump the fixture data into a method in case you want to access it directly TIP: In order to remove existing data from the database, Rails tries to disable referential integrity triggers (like foreign keys and check constraints). If you are getting annoying permission errors on running tests, make sure the database user has privilege to disable these triggers in testing environment. (In PostgreSQL, only superusers can disable all triggers. Read more about PostgreSQL permissions [here](http://blog.endpoint.com/2012/10/postgres-system-triggers-error.html)) @@ -270,6 +270,8 @@ Finished tests in 0.009262s, 107.9680 tests/s, 107.9680 assertions/s. 1 tests, 1 assertions, 0 failures, 0 errors, 0 skips ``` +This will run all test methods from the test case. + You can also run a particular test method from the test case by running the test and providing the `test method name`. ```bash @@ -281,8 +283,6 @@ Finished tests in 0.009064s, 110.3266 tests/s, 110.3266 assertions/s. 1 tests, 1 assertions, 0 failures, 0 errors, 0 skips ``` -This will run all test methods from the test case. - The `.` (dot) above indicates a passing test. When a test fails you see an `F`; when a test throws an error you see an `E` in its place. The last line of the output is the summary. #### Your first failing test @@ -347,7 +347,11 @@ Finished tests in 0.047721s, 20.9551 tests/s, 20.9551 assertions/s. 1 tests, 1 assertions, 0 failures, 0 errors, 0 skips ``` -Now, if you noticed, we first wrote a test which fails for a desired functionality, then we wrote some code which adds the functionality and finally we ensured that our test passes. This approach to software development is referred to as _Test-Driven Development_ (TDD). +Now, if you noticed, we first wrote a test which fails for a desired +functionality, then we wrote some code which adds the functionality and finally +we ensured that our test passes. This approach to software development is +referred to as +[_Test-Driven Development_ (TDD)](http://c2.com/cgi/wiki?TestDrivenDevelopment). #### What an error looks like @@ -379,7 +383,11 @@ NameError: undefined local variable or method `some_undefined_variable' for #<Ar Notice the 'E' in the output. It denotes a test with error. -NOTE: The execution of each test method stops as soon as any error or an assertion failure is encountered, and the test suite continues with the next method. All test methods are executed in alphabetical order. +NOTE: The execution of each test method stops as soon as any error or an +assertion failure is encountered, and the test suite continues with the next +method. All test methods are executed in random order. The +[`config.active_support.test_order` option](http://edgeguides.rubyonrails.org/configuring.html#configuring-active-support) +can be used to configure test order. When a test fails you are presented with the corresponding backtrace. By default Rails filters that backtrace and will only print lines relevant to your diff --git a/guides/source/upgrading_ruby_on_rails.md b/guides/source/upgrading_ruby_on_rails.md index 909a92b9dd..20b90bdba0 100644 --- a/guides/source/upgrading_ruby_on_rails.md +++ b/guides/source/upgrading_ruby_on_rails.md @@ -276,6 +276,22 @@ class Notifier < ActionMailer::Base end ``` +### Foreign Key Support + +The migration DSL has been expanded to support foreign key definitions. If +you've been using the Foreigner gem, you might want to consider removing it. +Note that the foreign key support of Rails is a subset of Foreigner. This means +that not every Foreigner definition can be fully replaced by it's Rails +migration DSL counterpart. + +The migration procedure is as follows: + +1. remove `gem "foreigner"` from the Gemfile. +2. run `bundle install`. +3. run `bin/rake db:schema:dump`. +4. make sure that `db/schema.rb` contains every foreign key definition with +the necessary options. + Upgrading from Rails 4.0 to Rails 4.1 ------------------------------------- diff --git a/railties/lib/rails/application.rb b/railties/lib/rails/application.rb index 8da73db821..b11815e013 100644 --- a/railties/lib/rails/application.rb +++ b/railties/lib/rails/application.rb @@ -428,8 +428,8 @@ module Rails # and the order specified by the +railties_order+ config. # # While when running initializers we need engines in reverse - # order here when copying migrations from railties we need then in the same - # order as given by +railties_order+ + # order here when copying migrations from railties we need them in the same + # order as given by +railties_order+. def migration_railties # :nodoc: ordered_railties.flatten - [self] end diff --git a/railties/lib/rails/engine.rb b/railties/lib/rails/engine.rb index dc8785c1c1..e1d5caf790 100644 --- a/railties/lib/rails/engine.rb +++ b/railties/lib/rails/engine.rb @@ -217,7 +217,7 @@ module Rails # <tt>url_helpers</tt> from <tt>MyEngine::Engine.routes</tt>. # # The next thing that changes in isolated engines is the behavior of routes. Normally, when you namespace - # your controllers, you also need to do namespace all your routes. With an isolated engine, + # your controllers, you also need to namespace all your routes. With an isolated engine, # the namespace is applied by default, so you can ignore it in routes: # # MyEngine::Engine.routes.draw do @@ -296,7 +296,7 @@ module Rails # helper MyEngine::SharedEngineHelper # end # - # If you want to include all of the engine's helpers, you can use #helper method on an engine's + # If you want to include all of the engine's helpers, you can use the #helper method on an engine's # instance: # # class ApplicationController < ActionController::Base @@ -312,7 +312,7 @@ module Rails # Engines can have their own migrations. The default path for migrations is exactly the same # as in application: <tt>db/migrate</tt> # - # To use engine's migrations in application you can use rake task, which copies them to + # To use engine's migrations in application you can use the rake task below, which copies them to # application's dir: # # rake ENGINE_NAME:install:migrations @@ -328,7 +328,7 @@ module Rails # # == Loading priority # - # In order to change engine's priority you can use +config.railties_order+ in main application. + # In order to change engine's priority you can use +config.railties_order+ in the main application. # It will affect the priority of loading views, helpers, assets and all the other files # related to engine or application. # |