views:

119

answers:

1

I've defined a signal handler function in my models.py file. At the bottom of that file, I use signals.post_save.connect(myhandler, sender=myclass) as recommended in the docs at http://docs.djangoproject.com/en/dev/topics/signals/.

However, when I run the test server, simple print-statement debugging shows that the models.py file gets imported twice and (as far as I can tell), this causes my signal handler to get registered twice. This means that every action is handled twice, which is obviously not the intended behaviour.

The first import seems to occur during the model checking phase, and the second happens right when the model itself is needed during the first request handled by the server.

Should I be registering my signals handlers elsewhere? Is this a bug in the 1.1 test server? Am I missing something else?

+3  A: 

The signature for the connect method is

def connect(self, receiver, sender=None, weak=True, dispatch_uid=None)

where the dispatch_uid parameter is an identifier used to uniquely identify a particular instance of a receiver. This will usually be a string, though it may be anything hashable. If receivers have a dispatch_uid attribute, the receiver will not be added if another receiver already exists with that dispatch_uid.

So, you could specify a dispatch_uid in your connect call to see if that eliminates the problem.

Vinay Sajip
Fantastic! this is exactly what I was looking for, it solves my problem. It still feels a little clumsy to have to do this for every unique signal handler I create, but whatever works... I wonder why this behavior changed in 1.1.
Paul McMillan
This behavior changes because signals are not well-supported. Almost everything you ever need can be done by overriding `save`.
S.Lott
See http://stackoverflow.com/questions/170337/django-signals-vs-overriding-save-method for a discussion about when to override `save` and when to use signals
Vinay Sajip
Interesting stuff, but in this case, I actually do need to be using the signal.
Paul McMillan
@Paul: the double import only happens when you import your modules in more than one way. So you can also fix this problem by going through your code and verifying all imports are identical. I.e. if you "import project.app.models" make sure it's always done that way and never as "import app.models" or just "import models".
Van Gale
@Van Gale: That's really useful information. I'd never considered that. I bet that the double import is probably occuring because the DB check stage uses project.app.models while all my code has been using app.models. I suppose that's one reason to use project.app.models. Are there others? I should split this out to a different question...
Paul McMillan