Package: django-transaction-signals-do-not-use
tl;drFor the common use case of running code after the current transaction is
successfully committed, usedjango-transaction-hooks. It has some rough
edges, but it’s sane.Why?Django doesn’t provide transaction signals because they’re a bad idea. Some of
the reasons will be apparent in the “Limitations” paragraph below. Other
reasons can be found in ticket14051and on the django-developers mailing
list. However, I’m fed up with having this argument. People will shoot
themselves into the foot anyway.This package will help you experience the problems
of transaction signals first-hand.Use it at your own risk. I wouldn’t.How?Add'transaction_signals'to yourINSTALLED_APPSsetting.This will monkey-patch Django’s transaction management features.You can then register receivers for transaction signals:from django.dispatch import receiver
from transaction_signals import post_commit

@receiver(post_commit)
def print_commits(sender, **kwargs):
    print("COMMIT on %s" % sender)SignalsSignals are available in thetransaction_signalspackage. Their semantics
are obvious, except when they aren’t.Connection signals:pre_openpost_openpre_closepost_closeAutocommit signals:pre_set_autocommitpost_set_autocommitTransaction signals:pre_commitpost_commitpre_rollbackpost_rollbackSavepoint signals:pre_savepointpost_savepointpre_savepoint_commitpost_savepoint_commitpre_savepoint_rollbackpost_savepoint_rollbacksenderis the alias of the database connection e.g.'default'. All
signals pass the database connection in the'connection'argument.
Furthermore,pre/post_openprovide aconn_paramsargument,pre/post_set_autocommitprovideautocommit, andpre/post_savepoint/_commit/_rollbackprovidesavepoint_id.LimitationsYou cannot assume thatpre/post_commitare sent whenever changes are
committed. Signals aren’t sent when the connection is in autocommit mode,
which is thedefault.You cannot assume thatpre/post_rollbackare sent whenever changes are
cancelled. Closing the connection to the database triggers an implicit
rollback.You cannot assume thatpre/post_closeare sent whenever an implicit
rollback happens. Losing the connection to the database also triggers an
implicit rollback.Afterpre/post_savepointis sent, you cannot assume that eitherpre/post_savepoint_commitorpre/post_savepoint_rollbackwill be sent
with the samesavepoint_id. The savepoint may be released or rolled back
together with an earlier savepoint or the entire transaction.You cannot usepre/post_set_autocommiton SQLite. Thesqlite3module
doesn’t work in non-autocommit mode.You cannot usepre/post_savepoint_commiton Oracle, MSSQL, or any other
database that doesn’t support releasing savepoints.This is only the tip of the iceberg. I cannot recommend you use this package
if you learnt anything in this section. In fact, I cannot recommend it at all.AlternativesFortunately, if you want to add custom logic to Django’s transaction handling,
you have several alternatives. They’re much less likely to result in anger,
facepalms, insanity, loss of self-esteem, and other regrettable side effects.You may put your custom logic:In a middleware, if you only care about transactions tied to requests whenATOMIC_REQUESTSis enabled.In a decorator that wrapsatomic, if you have more advanced needs,
especially if you want to track partial commits and rollbacks.In a database backend, if you want tight control over database operations.
Since there’s no public API, you’ll have to read the source and figure out
how Django works, rather than blindly hooking to signals that may or may not
be sent. django-transaction-hooks uses this technique.LicenseThis package is released under a dual license: WTFPLv2 and GPLv2.The distribution only includes the WTFPLv2 because the GPLv2 is too long.