post_syncdb is triggered twice, in unittest, even with dispatch_uid

[Xinkai]

Here is how to reproduce the bug.

1. Start a fresh project, set DB backend.
2. Start a new app called myapp. Add myapp to INSTALLED_APPS.
3. Create /myapp/management/__init__.py

   from django.db.models.signals import post_syncdb
   import myapp.models
   
   def my_callback(sender, **kwargs):
       print "Called!!!"
   
   post_syncdb.connect(my_callback, sender=myapp.models, dispatch_uid = "unique_string")
   

4. run './manage.py test myapp', or './manage.py test', 'Called!!!' will appear twice.

[Richard Terry]

I also see this in Django 1.3: django.db.backends.creation.BaseDatabaseCreation.create_test_db calls the syncdb and flush management commands, which both then call emit_post_sync_signal.

[Jannis Leidel]

This seems to be intentional as the two phased test database setup is done to first populate the tables with the general layout and then flushing them to get rid of the data that may have been loaded automatically during setup. I doubt that this is a bug per se but rather an unfortunate side effect of this technique. Marking as "wontfix" until there are other indicators that this isn't what we want.

[Michał Pasternak]

My use case for post_syncdb signal is, that I load custom SQL commands into my PostgreSQL database (mainly triggers and a few Pl/PGSQL functions).

I can take care of this triggering twice with "CREATE OR REPLACE" commands or using "DROP ... IF EXISTS" first, so this is not a big problem, but triggering this twice means it takes twice the time when I run unittests. And, when I run a single unittests or when I debug a single unittest, the time it takes is annoying for me.

Perhaps I can move the custom sql commands into South migration - just thought about that.

Just my $.25 on this issue. Thanks!

[Shai Berger]

Replying to @mpasternak:

My use case for post_syncdb signal is, that I load custom SQL commands into my PostgreSQL database (mainly triggers and a few Pl/PGSQL functions).

​https://docs.djangoproject.com/en/1.6/howto/initial-data/#database-backend-specific-sql-data

(It may end up deprecated in Django 1.7 -- but so are South migrations...)