Django database transaction signals (pre/post commit/rollback).
Monkey-patch signals into django.db.transaction.signals.*.
The following signals are defined and behave according to the description:
Sent prior to the transaction being committed. Exceptions raised in handlers will prevent the transaction from being committed, and will bubble up to the application.
Sent after the transaction is committed. The signal is sent via ~Signal.send_robust, meaning all handlers are executed. Exceptions raised in handlers are logged but will not bubble up to the application.
This is done because there’s nothing useful that allowing the exception to bubble up will achieve. It’s more important to execute all the handlers. Even if you assume there is something useful in raising the exception, if two handlers raise an exception, which one should be raised? Instead, both are logged and not raised.
Sent prior to the transaction being rolled-back. Exceptions raised in handlers will prevent the transaction from being rolled-back, and will bubble up to the application.
Sent after the transaction as been rolled-back. The signal is sent via ~Signal.send_robust, meaning all handlers are executed. Exceptions raised in handlers are logged but will not bubble up to the application.
A detailed rational for the exception smothering is in post_commit.
Send before the ???
Send after leaving transaction management. This signal isn’t sent if a TransactionManagementError is raised.
import djcelery_transactions.transaction_signals def _post_commit(**kwargs): print "The transaction has been committed!" django.db.transaction.signals.post_commit.connect(_post_commit)
This code was inspired by Grégoire Cachet’s implementation of similar functionality, which can be found on GitHub: https://gist.github.com/247844
This module must be imported before you attempt to use the signals.