Reputation: 12541
I have a myapp/management/__init__.py
that is registering a post_syncdb
handler like so:
from django.db.models import signals
from features import models as features
def create_features(app, created_models, verbosity, **kwargs):
print "Creating features!"
# Do stuff...
signals.post_syncdb.connect(create_features, sender=features)
I've verified the following:
features
and myapp
are in settings.INSTALLED_APPS
myapp.management
is getting loaded prior to the syncdb running (verified via a print statement at the module level)features
app is getting processed by syncdb
, and it is emitting a post_syncdb
signal (verified by examining syncdb
's output with --verbosity=2
.However, myapp.management.create_features
is never called. What am I missing?
Upvotes: 3
Views: 3081
Reputation: 77
Just came across the same issue, and the way I solved it was to remove the sender
from function arguments and check for it inside the callback function.
from django.db.models import signals
from features import models as features
def create_features(app, created_models, verbosity, **kwargs):
print "Creating features!"
if app != features #this will work as it compares models module instances
return
# Do stuff...
signals.post_syncdb.connect(create_features)
That way you can keep them in your management module like Django docs suggest. I agree that it should work like you suggested. You could probably dig into the implementation of the Signal class in django.dispatch
.
Upvotes: 1
Reputation: 31139
The point is in the sender
. Your custom callback is called only if sender
worked out. In my case the sender
was db.models
and it is not worked out if syncdb called not the first time, i.o. the synced models are exist in database. In the documents it is written, but do not putted a proper emphasis.
sender
The models module that was just installed. That is, if syncdb just installed an app called "foo.bar.myapp", sender will be the foo.bar.myapp.models module.
So my solution was drop the database and install my app again.
Upvotes: 0