mirror of https://github.com/rails/rails
Capitalize framework names [ci-skip]
This commit is contained in:
parent
4c2fdbfac5
commit
ed08eea99f
|
@ -61,7 +61,7 @@ module ActiveJob
|
|||
#
|
||||
# Note: The adapter provided by this method must provide some additional
|
||||
# methods from those expected of a standard ActiveJob::QueueAdapter
|
||||
# in order to be used with the active job test helpers. Refer to
|
||||
# in order to be used with the Active Job test helpers. Refer to
|
||||
# ActiveJob::QueueAdapters::TestAdapter.
|
||||
def queue_adapter_for_test
|
||||
ActiveJob::QueueAdapters::TestAdapter.new
|
||||
|
|
|
@ -401,7 +401,7 @@ To keep using the current cache store, you can turn off cache versioning entirel
|
|||
end
|
||||
|
||||
ActiveSupport.on_load(:active_record_fixture_set) do
|
||||
# Encrypt active record fixtures
|
||||
# Encrypt Active Record fixtures
|
||||
if ActiveRecord::Encryption.config.encrypt_fixtures
|
||||
ActiveRecord::Fixture.prepend ActiveRecord::Encryption::EncryptedFixtures
|
||||
end
|
||||
|
|
|
@ -29,7 +29,7 @@ require "active_support/core_ext/date/conversions"
|
|||
# It should be noted that when using ::JSON.{generate,dump} directly, ActiveSupport's encoder is
|
||||
# bypassed completely. This means that as_json won't be invoked and the JSON gem will simply
|
||||
# ignore any options it does not natively understand. This also means that ::JSON.{generate,dump}
|
||||
# should give exactly the same results with or without active support.
|
||||
# should give exactly the same results with or without Active Support.
|
||||
|
||||
module ActiveSupport
|
||||
module ToJsonWithActiveSupportEncoder # :nodoc:
|
||||
|
|
|
@ -500,7 +500,7 @@ Transaction Callbacks
|
|||
|
||||
### Dealing With Consistency
|
||||
|
||||
There are two additional callbacks that are triggered by the completion of a database transaction: [`after_commit`][] and [`after_rollback`][]. These callbacks are very similar to the `after_save` callback except that they don't execute until after database changes have either been committed or rolled back. They are most useful when your active record models need to interact with external systems which are not part of the database transaction.
|
||||
There are two additional callbacks that are triggered by the completion of a database transaction: [`after_commit`][] and [`after_rollback`][]. These callbacks are very similar to the `after_save` callback except that they don't execute until after database changes have either been committed or rolled back. They are most useful when your Active Record models need to interact with external systems which are not part of the database transaction.
|
||||
|
||||
Consider, for example, the previous example where the `PictureFile` model needs to delete a file after the corresponding record is destroyed. If anything raises an exception after the `after_destroy` callback is called and the transaction rolls back, the file will have been deleted and the model will be left in an inconsistent state. For example, suppose that `picture_file_2` in the code below is not valid and the `save!` method raises an error.
|
||||
|
||||
|
|
Loading…
Reference in New Issue