Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#24816 closed Cleanup/optimization (fixed)

Clarify docs about preventing duplicate signals

Reported by: Timothy Makobu Owned by: Jason Held
Component: Documentation Version: 3.1
Severity: Normal Keywords: signals
Cc: django@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hello,

In the docs here https://docs.djangoproject.com/en/1.8/topics/signals/#preventing-duplicate-signals It implies that a receiver can be called multiple times for the same event. When would this happen? Is it still a problem in 1.8?

Change History (10)

comment:1 by Russell Keith-Magee, 9 years ago

Resolution: invalid
Status: newclosed

The ticket tracker is for tracking known problems, not asking questions. If you want to ask a question about usage, please use the Django-users mailing list.

However; to answer your question: Yes, it is still a problem, and no, there isn't much we can do about it (other than what is already listed in in the docs). The problem is that due to Python's import process, it's possible for the same module to be imported twice, resulting in a handler being registered twice.

comment:2 by Keryn Knight, 9 years ago

Component: Core (Other)Documentation

The reason timkofu has raised this ticket was because coming into IRC to find out what the circumstances were didn't yield definitive results, and while the phrasing of the original ticket may have left you thinking it was a question for django-users, it's not, really. Given I was the one suggesting opening a ticket to get the docs improved, I'm going to chime in.

I have no idea what In some circumstances, the code connecting receivers to signals may run multiple times might mean, these days, given much of the problem stemmed (IIRC) from the old project layout allowing for multiple import paths, and the lack of something like AppConfig.ready.

If it is still a problem, as has been alluded to, the nature of how multiple runs might be encountered ought to be documented rather than just hand-waving it away as "in some circumstances" and leaving the user wondering why they need dispatch_uid. There used to be a whole Wiki page devoted to the issue; I'd hope if it's still an issue, some of the explanation therein could be subsumed into the actual docs.
(Or just drop the whole bit entirely and document signals as taking a dispatch_uid everywhere, given that is essentially the solution (and has been for as long as I can remember))

I'm reclassifying this as documentation improvement, in the hope that it could be re-opened on that basis.

comment:3 by Keryn Knight, 9 years ago

Cc: django@… added

comment:4 by Tim Graham, 9 years ago

Resolution: invalid
Status: closednew
Summary: Preventing duplicate signalsClarify docs about preventing duplicate signals
Triage Stage: UnreviewedAccepted

comment:5 by Jason Held, 4 years ago

Owner: changed from nobody to Jason Held
Status: newassigned

comment:6 by Mariusz Felisiak, 4 years ago

Has patch: set
Patch needs improvement: set

comment:7 by Mariusz Felisiak, 4 years ago

Patch needs improvement: unset
Triage Stage: AcceptedReady for checkin
Version: 1.83.1

comment:8 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 639142e2:

Fixed #24816 -- Clarified docs about preventing duplicate signals.

comment:9 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 703256f:

[3.1.x] Fixed #24816 -- Clarified docs about preventing duplicate signals.

Backport of 639142e24d41c5e5a508cb1280f32fd7ff159cca from master

comment:10 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 3ca2361d:

[3.0.x] Fixed #24816 -- Clarified docs about preventing duplicate signals.

Backport of 639142e24d41c5e5a508cb1280f32fd7ff159cca from master

Note: See TracTickets for help on using tickets.
Back to Top