Django signals and fixtures

December 10, 2012

Django signals are one of the more powerful tools we have. They let you focus in what you want to do, and the keep you dry. They can be also a real nightmare when there are lots of them, not well documented, and even one signal could perform tasks that sends signals to other handlers. Under this circumstances testing is your only ally, but creating fixtures is a tedious work, well, creating fixtures that works on medium complex projects is always a pain, but if you have lots of signals connected, then it turns into hell.

As the project is complex, you can’t simply dumpdata, so you must write your fixtures “by hand”. When you do this, and try to load them with loaddata, you realize that some of the database objects you manually created in your fixture, are magically generated when the fixture is loaded, and then, when it tries to load what you wrote, it fails because the data is already on db. The question is that, when your fixtures are loaded, they send signals, so you will need to note this. However the django developers provided us a way to skip those signals when a operation such as syncdb or loaddata is in progress. Whenever this happens, the signal handler will receive an extra keyword in **kwargs raw, so you can use it to avoid running a signal handler like this.

@receiver(post_save, sender=ModelA)
def signal_handler(sender, **kwargs):
    raw = kwargs.get('raw', False)
    if not raw:
        <do whatever>

Unfortunately you need to do this in all the signals you want to skip. I’m considering do it in all the signals handlers that perform database inserts or updates.