Opened 8 years ago

Closed 14 months ago

#5685 closed New feature (fixed)

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

Reported by: __hawkeye__ Owned by:
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: hv@…, real.human@…, carljm, alexkoshelev, 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 __hawkeye__ 8 years ago.
First-pass implementation of this functionality. Lacks documentation.
ticket_5685__revision_6809.diff (7.9 KB) - added by __hawkeye__ 8 years ago.
A few changes... described below.

Download all attachments as: .zip

Change History (23)

Changed 8 years ago by __hawkeye__

First-pass implementation of this functionality. Lacks documentation.

comment:1 Changed 8 years ago by __hawkeye__

  • Needs documentation set
  • Needs tests unset
  • Owner changed from nobody to __hawkeye__
  • Patch needs improvement unset
  • Status changed from new to assigned
  • Summary changed from Add ability to perform pre-runtime setup before executing code to [patch] Add ability to perform pre-runtime setup before executing code
  • Triage Stage changed from Unreviewed to Design 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 8 years ago by __hawkeye__

A few changes... described below.

comment:2 Changed 8 years ago by __hawkeye__

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 follow-up: Changed 8 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 8 years ago by jacob

  • Component changed from Uncategorized to Core framework

comment:5 in reply to: ↑ 3 Changed 8 years ago by __hawkeye__

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 7 years ago by __hawkeye__

  • Owner changed from __hawkeye__ to mtredinnick
  • Status changed from assigned to new

Reassigned to Malcolm at his request.

comment:7 Changed 7 years ago by mtredinnick

  • milestone set to post-1.0
  • Triage Stage changed from Design decision needed to Accepted

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

comment:8 Changed 7 years ago by mtredinnick

  • Owner mtredinnick deleted

comment:9 Changed 7 years ago by guettli

  • Cc hv@… added

comment:10 Changed 7 years ago by anonymous

  • Cc real.human@… added

comment:11 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:12 Changed 6 years ago by carljm

  • Cc carljm added

comment:13 Changed 6 years ago by alexkoshelev

  • Cc alexkoshelev added

comment:14 Changed 6 years ago by obeattie

  • Cc oliver@… added

comment:15 Changed 6 years ago by gonz

  • Cc gonz added

comment:16 Changed 4 years ago by jdunck

  • Cc jdunck@… added

comment:17 Changed 4 years ago by gabrielhurley

  • Severity set to Normal
  • Type set to New feature

comment:18 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:19 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:20 Changed 3 years ago by gonz

  • Cc gonz removed

comment:21 Changed 14 months ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed

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