CODEWITHSUNDEEP
pythondjango
goh
goh

Reputation: 29511

django: order of post_syncdb signals

I followed the instructions and created my post_syncdb signal inside app/management/__init__.py:

from django.db.models.signals import post_syncdb
from django.contrib.auth.models import Group, Permission
import payment.models as payModels


def initialization(sender, **kwargs):
    """ initialization when appliation starts """
    agents = Group.objects.get(name = "agents")
    import pdb
    pdb.set_trace()
    if not agents.permissions.filter(codename="can_buy_package").exists():
        perm = Permission.objects.get(codename="can_buy_package")
        agents.permissions.add(perm)

post_syncdb.connect(initialization, sender= payModels)

the signal runs, but using the python debugger there, it seems at that particular time no permissions, even the standard ones were created for my models inside the same app.

can someone advise?

-----------------------updated---------------------------

After Chris's comments, I took a look at the dispatcher class and inserted debug messages into the related files to understand more.

Essentially, in my app (which was further down the list in INSTALLED_APPS than contenttype and auth ) its post_syncdb handlers were added to the signal first. Turns out because during setup, Django looks for custom commands to install inside the the app's management/commands folder, signal handlers inside my management/init.py was executed.

I then tried to put the post_syncdb.connect inside my models.py. Running a trace shows that using haystack might also run into similar issue

(, '/Users/foo/.virtualenvs/property/lib/python2.6/site-packages/django/utils/importlib.py', 35, 'import_module', [' import(name)\n '], 0), (, '/Users/foo/.virtualenvs/property/lib/python2.6/site-packages/haystack/init.py', 121, 'autodiscove r', ['
importlib.import_module("%s.search_indexes" % app)\n'], 0), (, '/Users/foo/Documents/workspace/prop
erty_buyer/haystack_sites.py', 2, '', ['haystack.autodiscover()\n'], 0), (, '/Users/foo/.virtualenvs/prop
erty/lib/python2.6/site-packages/django/utils/importlib.py', 35, 'import_module', [' import(name)\n'], 0), (, '/Us
ers/foo/.virtualenvs/property/lib/python2.6/site-packages/haystack/init.py', 151, 'handle_registrations', [' search_sites_conf = importlib
.import_module(settings.HAYSTACK_SITECONF)\n'], 0), (, '/Users/foo/.virtualenvs/property/lib/python2.6/site-packa
ges/haystack/init.py', 154, '', ['handle_registrations()\n'], 0), (, '/Users/foo/.virtualenvs/propert
y/lib/python2.6/site-packages/django/utils/importlib.py', 35, 'import_module', [' import(name)\n'], 0),

Hope this is useful for folks whose handlers are order dependent and run into similar cases

Upvotes: 2

Views: 1243

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239290

There's two things to note. First, the post_syncdb signal is sent after each app is synced, so it's sent once for each app, not just once at the end. Second, there appears to be an inherent and stable order to which handlers are applied when, but it's not controllable.

To elaborate on the second point, I've spent the better part of 30 minutes just staring at auth's permissions post_syncdb handler, and I can't see anything that actually ensures that it comes after the same handler for contenttypes. Yet, nevertheless, it uses ContentType freely, confident that everything is ready to go. My only conclusion is that the order of the apps in INSTALLED_APPS matters, and it would appear that apps later in the list have their handlers processed before apps sooner in the list. My only conclusion is that auth benefits from starting with the letter A, and that few people would move it below contenttypes in the list as a result.

That would also mean that your app, which is inevitably defined after contenttypes in INSTALLED_APPS, has its signal handlers run before those of contenttypes, and there's your problem. It's not so much a race condition as it just always ahead of contenttypes.

You could, I suppose, move your app up in INSTALLED_APPS, but that might cause other unforeseen issues. You could also try changing the sender attribute to a different models file, perhaps even contenttypes, and maybe that might give it enough time to pop.

Upvotes: 2

Related Questions