@@ -24,7 +24,7 @@ In this guide, you can learn how to use {+django-odm+} to perform
24
24
**transactions**. Transactions allow you to run a series of operations
25
25
that change data only if the entire transaction is committed.
26
26
If any operation in the transaction does not succeed, {+django-odm+} stops the
27
- transaction and discards all data changes before they ever become
27
+ transaction and discards all changes to the data before they ever become
28
28
visible. This feature is called **atomicity**.
29
29
30
30
In MongoDB, transactions run within logical sessions. A
@@ -80,10 +80,10 @@ To start a database transaction, define an atomic block of code
80
80
by adding the ``@transaction.atomic`` decorator above your function.
81
81
This decorator guarantees the atomicity of any database operations
82
82
within the function. If the function successfully completes, the
83
- changes are committed MongoDB.
83
+ changes are committed to MongoDB.
84
84
85
85
The following example calls the ``create()`` method within a transaction,
86
- inserting a document into the ``sample_mflix.movies`` collection if the
86
+ which inserts a document into the ``sample_mflix.movies`` collection if the
87
87
transaction succeeds:
88
88
89
89
.. literalinclude:: /includes/interact-data/transactions.py
@@ -105,8 +105,8 @@ preceding example but uses a context manager to start a transaction:
105
105
Run Callbacks After a Transaction
106
106
---------------------------------
107
107
108
- If you want to perform certain actions only if a transaction successfully
109
- completes, you can use the ``transaction.on_commit()`` method . This method allows you to
108
+ To perform certain actions only if a transaction successfully completes,
109
+ you can use the ``transaction.on_commit()`` function . This function allows you to
110
110
register callbacks that run after a transaction is committed to the
111
111
database. Pass a function, or any callable object, as an argument to
112
112
``on_commit()``.
@@ -124,11 +124,12 @@ Handle Transaction Errors
124
124
-------------------------
125
125
126
126
To handle exceptions that occur during a transaction, add error handling
127
- logic around your atomic code block. If you include error handing logic inside
128
- the atomic block, {+framework+} might ignore these errors, resulting in unexpected
129
- behavior.
127
+ logic around your atomic code block. If you handle errors inside
128
+ the atomic block, you might obscure these errors from {+framework+}. Since
129
+ {+framework+} uses errors to determine whether to commit or roll
130
+ back a transaction, this can cause unexpected behavior.
130
131
131
- If a transaction does not succeed, your application does not revert any changes made
132
+ If a transaction does not succeed, Django does not revert any changes made
132
133
to a model's fields. To avoid inconsistencies between your models and database documents,
133
134
you might need to manually restore the original field values.
134
135
0 commit comments