title: Changing Django settings at runtime
body: <p>I'd like to expose some (app-specific) settings to the admin interface, so users can change them comfortably and also not have to restart Django.</p>
  
  <p>How should I go about this?</p>
  
  <p>I checked out the applications on <a href="http://djangopackages.com/grids/g/live-setting/" rel="noreferrer">http://djangopackages.com/grids/g/live-setting/</a> (btw django-constance was the most appealing) but really what all these apps are doing is storing values in a database, providing a web interface to change them, and caching. Aren't the first two features already built into Django?</p>
  
  <p>The biggest drawbacks I see are that none of the apps are drop-in replacements for the old location of these settings (settings.py), and require me to migrate to their notation, and often add another context processor to access them in templates.</p>
  
  <p>Couldn't I just do this?</p>
  
  <ol>
  <li>Create a model for my settings (this gives me the various types and validation)</li>
  <li>Instantiate one such object to hold my settings (this allows the users to edit them in the admin interface) - I could dump defaults as fixtures like for other models</li>
  <li>Wrap settings.py so it makes a database query for my settings - <a href="http://www.loose-bits.com/2011/04/extending-django-settings-with-derived.html" rel="noreferrer">http://www.loose-bits.com/2011/04/extending-django-settings-with-derived.html</a></li>
  </ol>
  
  <p>From my current, naive point of view the only drawbacks I see would be:</p>
  
  <ol>
  <li>Adding or changing the available settings requires a schema migration (south). - I can live with that.</li>
  <li>I have a model with possibly multiple instances but really only need a singleton. - That could actually be a useful feature at some point.</li>
  <li>Performance/Caching: Looking at <a href="http://code.djangoproject.com/svn/django/trunk/django/conf/" rel="noreferrer">http://code.djangoproject.com/svn/django/trunk/django/conf/</a> I'd have to put a little bit of cleverness into the settings wrapper and/or model, so that model changes clear or update cached values. - doesn't seem to be rocket science.</li>
  <li>Doing the same in another project would require a similar effort again. - I think a single dictionary constant in settings.py, holding model name(s) and field names for the lookups is all that would differ.</li>
  </ol>
  
  <p>Wouldn't this be the best of both worlds - runtime admin (with all its perks), database backend, caching, and none of my settings.USED_TO_BE_IN_SETTINGS_DOT_PY would need any changing. Am I missing something?</p>