aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib
diff options
context:
space:
mode:
authorHongli Lai (Phusion) <hongli@phusion.nl>2008-09-16 12:42:26 +0200
committerHongli Lai (Phusion) <hongli@phusion.nl>2008-09-16 12:50:50 +0200
commit86a0e98a79d9f03f431e55fc95f83783865d49e2 (patch)
tree698ab4a2924a311cb48dbf4ceb96e19f5d7341d3 /activerecord/lib
parent1fbae81e7f2ed64ae7c219e5669c7d68c2188d7a (diff)
downloadrails-86a0e98a79d9f03f431e55fc95f83783865d49e2.tar.gz
rails-86a0e98a79d9f03f431e55fc95f83783865d49e2.tar.bz2
rails-86a0e98a79d9f03f431e55fc95f83783865d49e2.zip
Wrap overview documentation for ActiveRecord::Transactions::ClassMethods so that it's easier to read in a text editor with word wrapping enabled.
Diffstat (limited to 'activerecord/lib')
-rw-r--r--activerecord/lib/active_record/transactions.rb38
1 files changed, 23 insertions, 15 deletions
diff --git a/activerecord/lib/active_record/transactions.rb b/activerecord/lib/active_record/transactions.rb
index f639ae3802..75b2460cf7 100644
--- a/activerecord/lib/active_record/transactions.rb
+++ b/activerecord/lib/active_record/transactions.rb
@@ -16,20 +16,25 @@ module ActiveRecord
end
end
- # Transactions are protective blocks where SQL statements are only permanent if they can all succeed as one atomic action.
- # The classic example is a transfer between two accounts where you can only have a deposit if the withdrawal succeeded and
- # vice versa. Transactions enforce the integrity of the database and guard the data against program errors or database break-downs.
- # So basically you should use transaction blocks whenever you have a number of statements that must be executed together or
- # not at all. Example:
+ # Transactions are protective blocks where SQL statements are only permanent
+ # if they can all succeed as one atomic action. The classic example is a
+ # transfer between two accounts where you can only have a deposit if the
+ # withdrawal succeeded and vice versa. Transactions enforce the integrity of
+ # the database and guard the data against program errors or database
+ # break-downs. So basically you should use transaction blocks whenever you
+ # have a number of statements that must be executed together or not at all.
+ # Example:
#
# transaction do
# david.withdrawal(100)
# mary.deposit(100)
# end
#
- # This example will only take money from David and give to Mary if neither +withdrawal+ nor +deposit+ raises an exception.
- # Exceptions will force a ROLLBACK that returns the database to the state before the transaction was begun. Be aware, though,
- # that the objects will _not_ have their instance data returned to their pre-transactional state.
+ # This example will only take money from David and give to Mary if neither
+ # +withdrawal+ nor +deposit+ raises an exception. Exceptions will force a
+ # ROLLBACK that returns the database to the state before the transaction was
+ # begun. Be aware, though, that the objects will _not_ have their instance
+ # data returned to their pre-transactional state.
#
# == Different Active Record classes in a single transaction
#
@@ -63,17 +68,20 @@ module ActiveRecord
#
# == Save and destroy are automatically wrapped in a transaction
#
- # Both Base#save and Base#destroy come wrapped in a transaction that ensures that whatever you do in validations or callbacks
- # will happen under the protected cover of a transaction. So you can use validations to check for values that the transaction
- # depends on or you can raise exceptions in the callbacks to rollback, including <tt>after_*</tt> callbacks.
+ # Both Base#save and Base#destroy come wrapped in a transaction that ensures
+ # that whatever you do in validations or callbacks will happen under the
+ # protected cover of a transaction. So you can use validations to check for
+ # values that the transaction depends on or you can raise exceptions in the
+ # callbacks to rollback, including <tt>after_*</tt> callbacks.
#
# == Exception handling and rolling back
#
- # Also have in mind that exceptions thrown within a transaction block will be propagated (after triggering the ROLLBACK), so you
- # should be ready to catch those in your application code.
+ # Also have in mind that exceptions thrown within a transaction block will
+ # be propagated (after triggering the ROLLBACK), so you should be ready to
+ # catch those in your application code.
#
- # One exception is the ActiveRecord::Rollback exception, which will trigger a ROLLBACK when raised,
- # but not be re-raised by the transaction block.
+ # One exception is the ActiveRecord::Rollback exception, which will trigger
+ # a ROLLBACK when raised, but not be re-raised by the transaction block.
module ClassMethods
# See ActiveRecord::Transactions::ClassMethods for detailed documentation.
def transaction(&block)