Opened 9 years ago

Closed 2 years ago

#5685 closed New feature (fixed)

[patch] Add ability to perform pre-runtime setup before executing code

Reported by: Ben Slavin Owned by:
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: hv@…, real.human@…, Carl Meyer, Alexander Koshelev, oliver@…, jdunck@… Triage Stage: Accepted
Has patch: no Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Django should allow developers to elegantly inject functionality prior to general code execution.

This is useful if something needs to happen before models are loaded (register as a class_prepared listener). Malcolm indicated that he is aware of other cases where this could be useful.

This issue has been discussed briefly on django-users. http://groups.google.com/group/django-users/browse_thread/thread/2f395d5b50086aea/

Attachments (2)

ticket_5685__revision_6453.patch (7.8 KB) - added by Ben Slavin 9 years ago.
First-pass implementation of this functionality. Lacks documentation.
ticket_5685__revision_6809.diff (7.9 KB) - added by Ben Slavin 9 years ago.
A few changes... described below.

Download all attachments as: .zip

Change History (23)

Changed 9 years ago by Ben Slavin

First-pass implementation of this functionality. Lacks documentation.

comment:1 Changed 9 years ago by Ben Slavin

Needs documentation: set
Owner: changed from nobody to Ben Slavin
Status: newassigned
Summary: Add ability to perform pre-runtime setup before executing code[patch] Add ability to perform pre-runtime setup before executing code
Triage Stage: UnreviewedDesign decision needed

I have attached a first-pass at solving this. It currently lacks documentation.

One side-effect (bonus?) of the implementation method I chose fixes the ModPython handler to no longer reprocess settings.MIDDLEWARE_CLASSES on every request. I don't think that this will have any negative impact (in fact it should speed things up), but I wanted to mention it.

Changed 9 years ago by Ben Slavin

A few changes... described below.

comment:2 Changed 9 years ago by Ben Slavin

Summary of changes

django/conf/global_settings.py

  • Added RUNTIME_SETUP_FUNCTIONS (default empty).

django/core/handlers/wsgi.py

  • Locking and middleware loading calls moved to HandlerState.ensure_state.

django/core/handlers/base.py

  • Added HandlerState class and handler_state global.
  • HandlerState handles loading middleware and runtime environment setup (ensure_state method).
  • Uses locking semantics to ensure things are only performed once per-process.

django/core/handlers/modpython.py

  • Removed explicit middleware loading, moved to ensure_state.

django/core/management/commands/shell.py

  • Perform runtime setup for shell command.

django/utils/setup.py

  • Defined setup_runtime function to run settings.RUNTIME_SETUP_FUNCTIONS.

django/test/client.py

  • Removed explicit middleware loading, moved to ensure_state.

comment:3 Changed 9 years ago by Jacob

Needs tests: set

Can you explain what the use case is here? I understand what you'd like to add, but not why you'd like to add it.

comment:4 Changed 9 years ago by Jacob

Component: UncategorizedCore framework

comment:5 in reply to:  3 Changed 9 years ago by Ben Slavin

Replying to jacob:

Can you explain what the use case is here? I understand what you'd like to add, but not why you'd like to add it.

The primary reason I'm looking to do this is to register listeners of the class_prepared signal. We have a few things that we need to do or add to all models and there's no good way to do this without the ability to listen for class_prepared. Unfortunately, the signal is called so early in the life of a Django process that we can't reliably register a listener before the models are created.

I'd imagine that there are other things people might want to do to the environment before anything is run, but none immediately come to mind. Malcolm seemed to have a few other ideas when this was discussed on django-users, but didn't explicitly mention what they were.

comment:6 Changed 8 years ago by Ben Slavin

Owner: changed from Ben Slavin to Malcolm Tredinnick
Status: assignednew

Reassigned to Malcolm at his request.

comment:7 Changed 8 years ago by Malcolm Tredinnick

milestone: post-1.0
Triage Stage: Design decision neededAccepted

Pushing to after 1.0 now. It's a feature addition that could potentially cause unexpected side-effects.

comment:8 Changed 8 years ago by Malcolm Tredinnick

Owner: Malcolm Tredinnick deleted

comment:9 Changed 8 years ago by Thomas Güttler

Cc: hv@… added

comment:10 Changed 8 years ago by anonymous

Cc: real.human@… added

comment:11 Changed 8 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:12 Changed 7 years ago by Carl Meyer

Cc: Carl Meyer added

comment:13 Changed 7 years ago by Alexander Koshelev

Cc: Alexander Koshelev added

comment:14 Changed 7 years ago by Oliver Beattie

Cc: oliver@… added

comment:15 Changed 7 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra added

comment:16 Changed 6 years ago by Jeremy Dunck

Cc: jdunck@… added

comment:17 Changed 6 years ago by Gabriel Hurley

Severity: Normal
Type: New feature

comment:18 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:19 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:20 Changed 5 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra removed

comment:21 Changed 2 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

The app-loading refactor clarified Django's start-up sequence and a solution for registering class_prepared receivers was documented.

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