Opened 2 years ago

Closed 22 months ago

Last modified 4 weeks 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


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/
    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 './ test myapp', or './ test', 'Called!!!' will appear twice.

Attachments (0)

Change History (4)

comment:1 Changed 2 years ago by radiac

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 22 months ago by jezdez

  • Resolution set to wontfix
  • Status changed from new to closed

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 Changed 22 months ago by jezdez

  • Triage Stage changed from Unreviewed to Design decision needed

comment:4 Changed 4 weeks ago by 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).

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!

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.