Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#18034 closed Uncategorized (duplicate)

Support for signal after settings have been read

Reported by: Mitar Owned by: nobody
Component: Core (Other) Version: 1.4
Severity: Normal Keywords:
Cc: mmitar@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I would ask for support for a Django signal after settings have been read. The reason is that this would allow some post-processing just after the Django has been loaded, without having to add that code in settings file itself (which is bad practice and also prevents extensibility).

For example, mongoengine connection could be cleanly established in this way.

Change History (4)

comment:1 Changed 5 years ago by Simon Charette

Can you elaborate on the reasons this is needed for mongodbengine? Which settings have to be added? Are you referring to this?

comment:2 Changed 5 years ago by Mitar

I am talking about MongoEngine. For connecting they propose to add connect call to settings. Something like:


import mongo

The problem is that this does not allow me to override MONGODB_DATABASE in some other settings file. For example, I often use one development settings file and another production which includes everything from the first and overrides things for production. But with that approach this is not possible as mongoengine.connect is called too soon. And furthermore, it is not a clean design to call things from settings file.

MongoEngine is just one example. I believe this pattern could be used anywhere you want to do some additional preprocessing before letting Django do its work, but you want to have access to settings.

comment:3 Changed 5 years ago by Russell Keith-Magee

Resolution: duplicate
Status: newclosed

This isn't a new suggestion -- e.g., see #13024.

However, it may not be obvious why this is a duplicate of #3591.

The underlying problem here is that Django doesn't have a clean 'startup' sequence. There's no place where you can put logic that you want to execute once when the stack is initialised.

This is also one of the reasons why a signal isn't the best solution for this problem. In order for a signal to be triggered, it needs to be registered; signal registrations need to happen once, when the stack is initialised. Therefore, there's a 'chicken and egg' problem with using a signal that triggers on stack startup.

In order to solve #3591 (currently referred to as the "App refactor") we need to introduce a clean startup sequence for apps. This will provide a reliable place to put stack startup logic.

comment:4 Changed 5 years ago by Mitar

Thanks for the explanation.

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