CODEWITHSUNDEEP
djangonotificationssignals
deadlock
deadlock

Reputation: 7310

In Django, what does it mean to generate an action in a separate signal?

In Django, what does it mean to generate an action in a separate signal?

For example, is this documentation here: https://github.com/brantyoung/django-notifications

It states: Generating notifications is probably best done in a separate signal.

Upvotes: 0

Views: 238

Answers (2)

pram
pram

Reputation: 1513

In the documentation you mentioned, there are two signals used by the example. The first one is notifications.notify and the other one is django.db.models.signals.post_save.

In order to use the notification app, basically you only need the first signal. For example, anywhere in your code you can write:

notify.send(request.user, verb='reached level 10')

However, the writer suggest that you should emit the notify signal after (or when) you handle another signal. Hence the example below:

def my_handler(sender, instance, created, **kwargs):
    #other routines here
    notify.send(instance, verb='was saved')

post_save.connect(my_handler, sender=MyModel)

That is, you send the notify signal as a part of the post_save signal handler.

Upvotes: 1

Timmy O'Mahony
Timmy O'Mahony

Reputation: 53990

Django has a signalling system that allows you to easily attach functions (signal handlers) that will fired when a certain event happens. There are a number of default events such as when a model object is saved or deleted, but you can also create your own events making it easy to later attach code:

https://docs.djangoproject.com/en/dev/topics/signals/

Django includes a “signal dispatcher” which helps allow decoupled applications get notified when actions occur elsewhere in the framework. In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They’re especially useful when many pieces of code may be interested in the same events.

The very important thing to note with these signals is that it's easy to think that these actions are fired asynchronously outside of the request/response loop, but this is not the case. They are simply a intuitive way of adding actions to events (i.e. when X is saved, do Y).

Upvotes: 1

Related Questions