Opened 16 years ago

Closed 10 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: dev
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 16 years ago.
First-pass implementation of this functionality. Lacks documentation.
ticket_5685__revision_6809.diff (7.9 KB ) - added by Ben Slavin 16 years ago.
A few changes... described below.

Download all attachments as: .zip

Change History (23)

by Ben Slavin, 16 years ago

First-pass implementation of this functionality. Lacks documentation.

comment:1 by Ben Slavin, 16 years ago

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.

by Ben Slavin, 16 years ago

A few changes... described below.

comment:2 by Ben Slavin, 16 years ago

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 by Jacob, 16 years ago

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 by Jacob, 16 years ago

Component: UncategorizedCore framework

in reply to:  3 comment:5 by Ben Slavin, 16 years ago

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 by Ben Slavin, 16 years ago

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

Reassigned to Malcolm at his request.

comment:7 by Malcolm Tredinnick, 16 years ago

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 by Malcolm Tredinnick, 16 years ago

Owner: Malcolm Tredinnick removed

comment:9 by Thomas Güttler, 15 years ago

Cc: hv@… added

comment:10 by anonymous, 15 years ago

Cc: real.human@… added

comment:11 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:12 by Carl Meyer, 14 years ago

Cc: Carl Meyer added

comment:13 by Alexander Koshelev, 14 years ago

Cc: Alexander Koshelev added

comment:14 by Oliver Beattie, 14 years ago

Cc: oliver@… added

comment:15 by Gonzalo Saavedra, 14 years ago

Cc: Gonzalo Saavedra added

comment:16 by Jeremy Dunck, 13 years ago

Cc: jdunck@… added

comment:17 by Gabriel Hurley, 13 years ago

Severity: Normal
Type: New feature

comment:18 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:19 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:20 by Gonzalo Saavedra, 12 years ago

Cc: Gonzalo Saavedra removed

comment:21 by Aymeric Augustin, 10 years ago

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