Opened 12 years ago

Closed 12 years ago

Last modified 10 years ago

#17977 closed Bug (wontfix)

post_syncdb is triggered twice, in unittest, even with dispatch_uid

Reported by: Xinkai Owned by: nobody
Component: Testing framework Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (5)

comment:1 by Richard Terry, 12 years ago

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.

comment:2 by Jannis Leidel, 12 years ago

Resolution: wontfix
Status: newclosed

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.

comment:3 by Jannis Leidel, 12 years ago

Triage Stage: UnreviewedDesign decision needed

comment:4 by Michał Pasternak, 10 years ago

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!

in reply to:  4 comment:5 by Shai Berger, 10 years ago

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...)

Note: See TracTickets for help on using tickets.
Back to Top