Changeset 2462
- Timestamp:
- 03/01/06 19:37:06 (3 years ago)
- Files:
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/branches/magic-removal/django/db/transaction.py
r2457 r2462 19 19 class TransactionManagementError(Exception): 20 20 """ 21 This is the exception that is thrown when22 something bad happens with transactionmanagement.21 This exception is thrown when something bad happens with transaction 22 management. 23 23 """ 24 24 pass 25 25 26 26 # The state is a dictionary of lists. The key to the dict is the current 27 27 # thread and the list is handled as a stack of values. … … 38 38 the appropriate leave_transaction_management call, since the actual state is 39 39 managed as a stack. 40 41 42 from the settings, if there is no surrounding block (dirty is al lways false40 41 The state and dirty flag are carried over from the surrounding block or 42 from the settings, if there is no surrounding block (dirty is always false 43 43 when no current block is running). 44 44 """ … … 56 56 Leaves transaction management for a running thread. A dirty flag is carried 57 57 over to the surrounding block, as a commit will commit all changes, even 58 those from outside (commits are on connection level).58 those from outside. (Commits are on connection level.) 59 59 """ 60 60 thread_ident = thread.get_ident() … … 64 64 raise TransactionManagementError("This code isn't under transaction management") 65 65 if dirty.get(thread_ident, False): 66 # I fixed it for you this time, but don't do it again!67 66 rollback() 68 67 raise TransactionManagementError("Transaction managed block ended with pending COMMIT/ROLLBACK") … … 71 70 def is_dirty(): 72 71 """ 73 Checks if the current transaction requires a commit for changes to happen. 72 Returns True if the current transaction requires a commit for changes to 73 happen. 74 74 """ 75 75 return dirty.get(thread.get_ident(), False) … … 90 90 """ 91 91 Resets a dirty flag for the current thread and code streak. This can be used 92 to decide in a managed block of code to decide whether there should happen a93 commit or rollback.92 to decide in a managed block of code to decide whether a commit or rollback 93 should happen. 94 94 """ 95 95 thread_ident = thread.get_ident() … … 111 111 def managed(flag=True): 112 112 """ 113 Puts the transaction manager into a manual state -managed transactions have113 Puts the transaction manager into a manual state: managed transactions have 114 114 to be committed explicitely by the user. If you switch off transaction 115 115 management and there is a pending commit/rollback, the data will be … … 164 164 def autocommit(func): 165 165 """ 166 Decorator that activates commit on save. This is Django's default behav our;166 Decorator that activates commit on save. This is Django's default behavior; 167 167 this decorator is useful if you globally activated transaction management in 168 your settings file and want the default behaviour in some view functions. 169 """ 170 168 your settings file and want the default behavior in some view functions. 169 """ 171 170 def _autocommit(*args, **kw): 172 171 try: … … 176 175 finally: 177 176 leave_transaction_management() 178 179 177 return _autocommit 180 178 181 179 def commit_on_success(func): 182 180 """ 183 This decorator activates commit on response. This way if the viewfunction184 runs successfully, a commit is made ,if the viewfunc produces an exception,181 This decorator activates commit on response. This way, if the view function 182 runs successfully, a commit is made; if the viewfunc produces an exception, 185 183 a rollback is made. This is one of the most common ways to do transaction 186 184 control in web apps. 187 185 """ 188 189 186 def _commit_on_success(*args, **kw): 190 187 try: … … 203 200 finally: 204 201 leave_transaction_management() 205 206 202 return _commit_on_success 207 203 … … 209 205 """ 210 206 Decorator that activates manual transaction control. It just disables 211 automatic transaction control and doesn't do any commit/rollback of it 's own212 - it's up to the user to call the commit and rollback functions themselves.213 """214 207 automatic transaction control and doesn't do any commit/rollback of its 208 own -- it's up to the user to call the commit and rollback functions 209 themselves. 210 """ 215 211 def _commit_manually(*args, **kw): 216 212 try: … … 222 218 223 219 return _commit_manually 224 225 django/branches/magic-removal/django/middleware/transaction.py
r2457 r2462 6 6 Transaction middleware. If this is enabled, each view function will be run 7 7 with commit_on_response activated - that way a save() doesn't do a direct 8 commit, the commit is done when a successful lresponse is created. If an8 commit, the commit is done when a successful response is created. If an 9 9 exception happens, the database is rolled back. 10 10 """ 11 12 11 def process_request(self, request): 13 12 """Enters transaction management""" django/branches/magic-removal/docs/transactions.txt
r2458 r2462 9 9 10 10 The default behavior of Django is to commit on special model functions. If you 11 call ``model.save()`` or ``model.delete()``, that change will be committed immediately. 11 call ``model.save()`` or ``model.delete()``, that change will be committed immediately. 12 12 13 13 This is much like the auto-commit setting for most databases: as soon as you … … 20 20 21 21 A useful way to handle transactions is to tie them to the request and response 22 phases. 22 phases. 23 23 24 24 When a request starts, you start a transaction. If the response is produced … … 40 40 session creation will be part of the transaction. 41 41 42 The cache middleware isn't affected as it uses it's own database cursor (that is43 mapped to it's own database connection internally) and only the database based 44 cache is affected.42 The cache middleware isn't affected, as it uses its own database cursor (which 43 is mapped to its own database connection internally), and only the 44 database-based cache is affected. 45 45 46 46 Controlling transaction management in views 47 47 =========================================== 48 48 49 For many people, implicit request-based transactions will work wonderfully. 50 However, if you need to control the way that transactions are managed, 51 there are a set of decorators that you can apply to a function to change 52 t he way transactions are handled.49 For many people, implicit request-based transactions will work wonderfully. 50 However, if you need to control the way that transactions are managed, 51 you can use decorators that you can apply to a function to change the way 52 transactions are handled. 53 53 54 54 .. note:: … … 65 65 66 66 from django.db.transaction import autocommit 67 67 68 68 @transaction.autocommit 69 69 def viewfunc(request): 70 70 .... 71 71 72 Within ``viewfunc`` transactions will be com itted as soon as you call73 ``model.save()``, ``model.delete()``, or any similar function that writes to the72 Within ``viewfunc`` transactions will be committed as soon as you call 73 ``model.save()``, ``model.delete()``, or any other function that writes to the 74 74 database. 75 75 … … 77 77 --------------------- 78 78 79 You can use the ``commit_on_success`` decorator to use a single transaction for 79 You can use the ``commit_on_success`` decorator to use a single transaction for 80 80 all the work done in a function:: 81 81 … … 86 86 .... 87 87 88 If the function returns successfully then all work done will be committed. If an88 If the function returns successfully, then all work done will be committed. If an 89 89 exception is raised beyond the function, however, the transaction will be rolled 90 90 back. … … 94 94 95 95 Sometimes you need full control over your transactions. In that case, you can use the 96 ``commit_manually`` decorator which will make you run your own transaction management. 96 ``commit_manually`` decorator, which tells Django you'll be managing the transaction 97 on your own. 97 98 98 If you don't commit or rollback and did change data (so that the current transaction 99 is marked as dirty), you will get a ``TransactionManagementError`` exception saying so. 99 If you don't commit or rollback and did change data (so that the current 100 transaction is marked as dirty), you'll get a ``TransactionManagementError`` 101 exception. 100 102 101 103 Manual transaction management looks like:: … … 107 109 ... 108 110 # You can commit/rollback however and whenever you want 109 transaction.commit() 111 transaction.commit() 110 112 ... 111 113 112 114 # But you've got to remember to do it yourself! 113 115 try: … … 118 120 transaction.commit() 119 121 120 ..admonition:: An important note to users of earlier django releases:121 122 ..admonition:: An important note to users of earlier Django releases: 123 122 124 The database ``connection.commit`` and ``connection.rollback`` functions 123 125 (also called ``db.commit`` and ``db.rollback`` in 0.91 and earlier), no … … 129 131 130 132 Control freaks can totally disable all transaction management by setting 131 ``DISABLE_TRANSACTION_MANAGEMENT`` to ``True`` in yoursettings file.133 ``DISABLE_TRANSACTION_MANAGEMENT`` to ``True`` in the Django settings file. 132 134 133 135 If you do this, there will be no management whatsoever. The middleware will no … … 137 139 138 140 Thus, this is best used in situations where you want to run your own transaction 139 controlling middleware or do something really strange. In almost all situations 141 controlling middleware or do something really strange. In almost all situations, 140 142 you'll be better off using the default behavior or the transaction middleware 141 143 and only modify selected functions as needed.
