2009-12-02 3 views
9

En Django, la configuración se almacena en un archivo, settings.py. Este archivo es parte del código y va al repositorio. Solo los desarrolladores tratan con este archivo. El administrador trata con los modelos, los datos en la base de datos. Estos son los datos que edita el personal que no pertenece al departamento de desarrollo y los visitantes del sitio los visualizan en las plantillas.¿Cómo hacer que el personal pueda acceder a algunas configuraciones de Django?

El caso es que nuestro sitio y muchos otros tienen muchas opciones de configuración que deberían ser editadas por personal que no sea desarrollador. Estamos hablando de constantes autónomas para todo el sitio que realmente no tienen cabida en la base de datos. Ponerlos en la base de datos dará lugar a numerosas consultas sin sentido. El almacenamiento en caché podría aliviar eso, pero parece innecesariamente complejo manejar lo que se puede hacer con una sola línea en el archivo settings.py.

Me di cuenta this dbsettings app, pero es viejo y no mantenido. También noté que la aplicación de comercio electrónico django, Satchmo, incluye una bifurcación específica de caso de uso de esta aplicación dbsettings. Podríamos construir algo similar en nuestro sitio, una aplicación que almacena algunas configuraciones como pares clave/valor en una sola tabla de base de datos, pero realmente parece un enfoque equivocado. ¿Por qué poner algo en el DB que no pertenece solo para hacerlo más fácilmente editable por los no desarrolladores?

Tenemos una lista de configuraciones de todo el sitio en nuestro sitio Django que queremos que sean editables por administradores que no sean desarrolladores. ¿Cuál es la mejor manera de resolver esto?

+0

+1 porque saber esto podría hacer que sea más fácil administrar proyectos de Django en VCS. Los desarrolladores deben tener cuidado de no realizar cambios locales a settings.py de lo contrario. –

+0

el almacenamiento en caché lo aliviará (cuando la configuración local se ponga en la base de datos) a solo una consulta por instancia de proceso django. – Evgeny

+0

para reiniciar el servidor con el fin de volver a cargar la configuración, puede llamar al archivo "touch site.wsgi", p. con un trabajo cron, pero esto solo funcionará si su proceso wsgi se ejecuta en el modo daemon – Evgeny

Respuesta

6

Algo así como dbsettings (como has mencionado) parece ser el camino a seguir. Desde el reasons for existence para ese proyecto:

No todos los ajustes de pertenecer en settings.py, ya que tiene algunas limitaciones particulares :

  • ajustes son a nivel de proyecto. Esto no solo requiere que las aplicaciones atemperen settings.py, sino que también aumenta las posibilidades de nombrar conflictos .

  • Los ajustes son constantes en una instancia de Django. No pueden ser cambiado sin reiniciar la aplicación.

  • Los ajustes requieren un programador para ser cambiados. Esto es cierto incluso si la configuración no tiene ningún impacto funcional en ninguna otra cosa.

Si dbsettings no funciona para usted, a continuación, poner en práctica su propia, o un tenedor ella. No parece que sea demasiado arduo.

0

¿Qué hay de poner un sitesettings.py (o lo que sea) en algún lugar que sus administradores pueden acceder, a continuación, en settings.py hacer

from sitesettings import * 

que parece bueno y sencillo, pero que puede haber entendido mal o simplificado su problema :)

+1

Esta solución tampoco funciona porque solo los técnicos pueden editar archivos en el servidor y/o reiniciar el apache. – Apreche

6

En realidad soy un gran fan de dbsettings, y sigo teniendo la intención de publicar mi fork que lo parchea para trabajar con Django 1.1 (no es un gran cambio) . Parece que alguien tiene updated it already.

Sin embargo, es probable que tenga razón en que esto es excesivo para lo que necesita.Una cosa que he hecho antes es agregar una línea al final de settings.py que importa y analiza un archivo YAML. YAML es un lenguaje de marcas simple, que en su forma más básica es simplemente KEY: VALUE ...

CONSTANT1: MyValue 
CONSTANT2: Anothervalue 

Si pones esto en alguna parte los editores pueden acceder a ella, y luego al final del settings.py que acaba de hacer:

import yaml 
try: 
    globals().update(yaml.load(open('/path/to/my/yaml/file.yml'))) 
except: 
    pass 

Necesitará la biblioteca Python YAML para analizar el archivo YML.

La desventaja de este enfoque es que tendrá que reiniciar Apache para que recoja los cambios.

Editado para agregar No sería particularmente difícil construir una interfaz que pudiera editar este archivo, y proporcionar un botón que ejecute una secuencia de comandos para reiniciar Apache.

+0

Esta solución no funciona porque solo los técnicos pueden editar archivos en el servidor y/o reiniciar Apache. – Apreche

+0

No sería particularmente difícil construir una interfaz que pudiera editar este archivo, y proporcionar un botón que ejecute una secuencia de comandos para reiniciar Apache. –

+1

@Daniel - aunque en ese punto ya estás entrando en el mismo tipo de nivel de trabajo que requiere dbsettings. –

1

Si debe evitar el reinicio del servidor, un lugar lógico para la configuración es la base de datos como lo indicaron Dominic y Daniel, pero deberá invalidar el objeto de configuración almacenado en caché cada vez que se actualice.

Parece que es posible volver a establecer los valores en la memoria caché con low level cache API de Django. Todo lo que desea debe ser posible con estas llamadas:

cache.set('settings', local_settings) 
cache.add('settings', local_settings) 
local_settings = cache.get('settings') 
cache.delete('settings') 
Cuestiones relacionadas