Il peut arriver que l’on doive ‘calculer’ un critère de filtrage Q en combinant plusieurs Q dont les conditions seraient saisis par l’utilisateur. On se retrouve à faire des choses du style
La question est de savoir comment initialiser full_q avant de commencer la boucle. La réponse est toute simple, il existe un filtre Q identité, qui ne trie donc rien, c’est tout simplement Q ()
Il devient rapidement assez ennuyeux de n’avoir qu’un seul fichier Models.py pour y ranger tout les models de sa petite application django en cours de dev. On réfléchit alors quelques secondes et là, miracle (Euréka même), une idée jaillit.
Pourquoi ne pas utiliser un package. Aussitôt dit, aussitôt fait. Un petit repertoire Models, tout plein de fichier .py à l’intérieur pour nos models. Un splendide __init__.py qui importe les models que l’on veut que le syncdb trouve en parcourant automatiquement nos apps et le tour est jouer.
Oui … mais en fait Non.
Parce que là, Oh Misère, Oh désespoir, le vilain syncdb ne trouve aucun de nos modules. Et c’est normal. Il manque quelque chose, un truc pas du tout documenté dans la doc (il y a d’ailleurs un ticket à propos de ce manque de documentation).
Il faut indiquer, dans chaque classe modèle, à traver la classe Meta, à quelle application appartient notre models. Par exemple pour une classe Post appartenant à l’app blog_app, ça donnerait :
Et voilà, comme cela, ça fonctionne. Facile n’est ce pas ?
Enfin, quand on le sait.
Cette petite astuce n’est pas un scoop, bien au contraire. Vous avez pu la lire des dizaines de fois, sur des dizaines de site, présenté de plein de façon différente. Moi c’est @davidbgk qui m’en a parlé lorsque je me m’interrogeais sur comment faire cela proprement.
Mais d’un autre coté, il faut bien commencé par un premier post et ça me permet d’écrire un premier post Django. (et c’est dimanche en plus, faut pas trop être exigeant).
Donc un premier post, pour résoudre un problème tout simple à savoir faire en sorte d’avoir X versions de configurations différentes de django, une version par défaut (qui peut être celle de prod) et une version pour chaque développeurs, plus celles pour les environnement de tests, etc etc…
Ma version de cette solution est simple.
A la fin du settings.py , je rajoute ces quelques lignes , X fois, pour chacun des environnements :
Il suffit ensuite d’avoir les bons fichiers de local_settings_NOM.py en ignore dans son contrôleur de version de source et ça roule.