2009-12-02 7 views
9

Dans Django, les paramètres sont stockés dans un fichier, settings.py. Ce fichier fait partie du code et va dans le dépôt. Ce sont seulement les développeurs qui s'occupent de ce fichier. L'administrateur traite les modèles, les données dans la base de données. Ce sont les données que le personnel non-développeur modifie et les visiteurs du site voient s'afficher dans les modèles. Le fait est que notre site, et beaucoup d'autres, ont de nombreuses options de paramétrage qui devraient être éditées par du personnel non-développeur. Nous parlons de constantes autonomes à l'échelle du site qui n'ont vraiment pas leur place dans la base de données. Les mettre dans la base de données se traduira par de nombreuses requêtes inutiles. La mise en cache peut remédier à cela, mais cela semble inutilement complexe pour gérer ce qui peut être fait avec une seule ligne dans le fichier settings.py. J'ai remarqué this dbsettings app, mais il est vieux et non maintenu. J'ai également remarqué que l'application de commerce électronique django, Satchmo, inclut une fourchette spécifique au cas d'utilisation de cette application dbsettings. Nous pourrions construire quelque chose de similaire sur notre site, une application qui stocke certains paramètres en tant que paires clé/valeur dans une seule table de base de données, mais cela semble vraiment être la mauvaise approche. Pourquoi mettre quelque chose dans la BD qui ne lui appartient pas juste pour le rendre plus facilement modifiable par des non-développeurs?Comment rendre certains paramètres Django accessibles au personnel?

Nous avons une liste de paramètres à l'échelle du site sur notre site Django que nous souhaitons être modifiables par des administrateurs non développeurs. Quelle est la meilleure façon d'y parvenir?

+0

+1 car cela pourrait faciliter la gestion des projets Django dans VCS. Les développeurs doivent veiller à ne pas valider localement les modifications de settings.py. –

+0

la mise en cache permettra d'éviter cela (lorsque les paramètres locaux sont mis dans la base de données) à une seule requête par instance de processus django. – Evgeny

+0

pour redémarrer le serveur afin de recharger les paramètres, vous pouvez simplement appeler le fichier "touch site.wsgi", par exemple. avec une tâche cron, mais cela ne fonctionnera que si votre processus de wsgi fonctionne en mode démon – Evgeny

Répondre

6

Quelque chose comme dbsettings (comme vous l'avez mentionné) semble être le chemin à parcourir. De l'reasons for existence pour ce projet:

Tous les paramètres appartiennent à settings.py, car il a quelques limitations particulières :

  • Les paramètres sont à l'échelle du projet. Cela ne nécessite pas que les applications encombrent settings.py, mais augmente également les chances de nommer conflits.

  • Les paramètres sont constants dans une instance de Django. Ils ne peuvent pas être modifiés sans redémarrer l'application.

  • Les réglages nécessitent un programmateur pour pouvoir être modifiés. Ceci est vrai même si le réglage n'a aucun impact fonctionnel sur autre chose.

Si dbsettings ne fonctionne pas pour vous, puis mettre en œuvre votre propre, ou de la fourche elle. Il ne semble pas que ce serait trop difficile.

0

Que diriez-vous de mettre un sitesettings.py (ou autre) quelque part que vos admins peuvent accéder, puis à faire settings.py

from sitesettings import * 

Cela semble bon et simple, mais je l'ai mal compris ou trop simpliste votre problème :)

+1

Cette solution ne fonctionne pas non plus car seuls les techniciens peuvent éditer des fichiers sur le serveur et/ou redémarrer l'apache. – Apreche

6

Je suis en fait un grand fan de dbsettings, et de garder le sens de publier ma fourche qui le corrige pour travailler avec Django 1.1 (pas vraiment un grand changement) . On dirait que quelqu'un a updated it already.

Cependant, vous avez probablement raison de dire que c'est trop pour ce dont vous avez besoin.Une chose que j'ai faite avant est d'ajouter une ligne à la fin de settings.py qui importe et analyse un fichier YAML. YAML est un langage de balisage simple, qui, à sa plus simple est juste KEY: VALUE ...

CONSTANT1: MyValue 
CONSTANT2: Anothervalue 

Si vous mettez cette éditeurs quelque part y ont accès, puis à la fin de settings.py vous venez de faire:

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

Vous aurez besoin de la bibliothèque Python YAML pour analyser le fichier YML.

L'inconvénient de cette approche est que vous devrez redémarrer Apache pour l'obtenir pour ramasser les changements.

Edité ajouter Il ne serait pas particulièrement difficile de construire une extrémité avant qui pourrait modifier ce fichier, et fournir un bouton qui exécute un script pour redémarrer Apache.

+0

Cette solution ne fonctionne pas car seuls les techniciens peuvent modifier les fichiers sur le serveur et/ou redémarrer Apache. – Apreche

+0

Il ne serait pas particulièrement difficile de construire un frontal qui pourrait éditer ce fichier, et de fournir un bouton qui exécute un script pour redémarrer Apache. –

+1

@Daniel - mais à ce stade, vous obtenez le même type de niveau de travail que les réglages dbsettings. –

1

Si vous devez éviter le redémarrage du serveur, puis un endroit logique pour les paramètres est la base de données que Dominic et Daniel dit, mais vous aurez besoin d'invalider les paramètres mises en cache objet à chaque fois qu'il est mis à jour.

On dirait qu'il est possible de nouveau les valeurs situé dans le cache avec Django low level cache API. Tout ce que vous voulez devrait être réalisable avec ces appels:

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