This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description


For the common use case of running code after the current transaction is successfully committed, use django-transaction-hooks. It has some rough edges, but it’s sane.


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 ticket 14051 and 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.


Add 'transaction_signals' to your INSTALLED_APPS setting.

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

def print_commits(sender, **kwargs):
    print("COMMIT on %s" % sender)


Signals are available in the transaction_signals package. Their semantics are obvious, except when they aren’t.

Connection signals:

  • pre_open
  • post_open
  • pre_close
  • post_close

Autocommit signals:

  • pre_set_autocommit
  • post_set_autocommit

Transaction signals:

  • pre_commit
  • post_commit
  • pre_rollback
  • post_rollback

Savepoint signals:

  • pre_savepoint
  • post_savepoint
  • pre_savepoint_commit
  • post_savepoint_commit
  • pre_savepoint_rollback
  • post_savepoint_rollback

sender is the alias of the database connection e.g. 'default'. All signals pass the database connection in the 'connection' argument. Furthermore, pre/post_open provide a conn_params argument, pre/post_set_autocommit provide autocommit, and pre/post_savepoint/_commit/_rollback provide savepoint_id.


You cannot assume that pre/post_commit are sent whenever changes are committed. Signals aren’t sent when the connection is in autocommit mode, which is the default.

You cannot assume that pre/post_rollback are sent whenever changes are cancelled. Closing the connection to the database triggers an implicit rollback.

You cannot assume that pre/post_close are sent whenever an implicit rollback happens. Losing the connection to the database also triggers an implicit rollback.

After pre/post_savepoint is sent, you cannot assume that either pre/post_savepoint_commit or pre/post_savepoint_rollback will be sent with the same savepoint_id. The savepoint may be released or rolled back together with an earlier savepoint or the entire transaction.

You cannot use pre/post_set_autocommit on SQLite. The sqlite3 module doesn’t work in non-autocommit mode.

You cannot use pre/post_savepoint_commit on 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.


Fortunately, 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 when ATOMIC_REQUESTS is enabled.
  • In a decorator that wraps atomic, 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.


This package is released under a dual license: WTFPLv2 and GPLv2.

The distribution only includes the WTFPLv2 because the GPLv2 is too long.

Release History

Release History


This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django_transaction_signals_do_not_use-1.0-py2.py3-none-any.whl (8.8 kB) Copy SHA256 Checksum SHA256 2.7 Wheel Jan 11, 2014
django-transaction-signals-do-not-use-1.0.tar.gz (5.2 kB) Copy SHA256 Checksum SHA256 Source Jan 11, 2014

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting