Cette possibilité est importante pour deux raisons. D'abord elle apporte un degré de souplesse supplémentaire à la gestion des données. Cela permet par exemple de cloisonner (séparer physiquement le contenu des codes d'accès peut être une bonne stratégie de sécurité) ou de gérer un partitionnement (géographique par exemple) des entrées au niveau de Django, sans passer par une couche inférieure (telle que sqlrelay ou mysqlproxy).

Ensuite elle rend beaucoup plus immédiate l'intégration d'une application Django en milieu hostile. Un exemple serait une interface centralisant l'administration de bases de données utilisées par d'autres systèmes.

Implémentation

L'implémentation de cette nouveauté ne semble pas avoir été facile. Bien que l'architecture de Django soit très modulaire, cette réforme en profondeur de l'ORM touche à beaucoup de mécanismes centraux et complexes pour certains, qui ne doivent pas être perturbés. Et pas question bien sûr de réviser l'api d'accès aux données.

La solution retenue est d'ailleurs empreinte de précautions. Essentiellement, cela se gère comme suit (l'alias special_blog_db étant décrit dans settings.py):

Post.objects.using("special_blog_db").filter(active=True)

La sélection est on ne peut plus explicite, et suit parfaitement la logique de l'api.

On peut choisir une base de manière similaire pour les vues d'administration. L'enregistrement d'une entrée se fait par défaut sur la base d'où provient l'objet, mais on peut spécifier une autre base en paramètre à la méthode save(). Si l'on veut associer par défaut une base à un model, on peut tout naturellement le faire à l'aide d'un Manager, en surchargeant la méthode get_query_set() avec un using().

En attendant Django 1.2

Ce merge coincide avec le planning de la version 1.2alpha de Django. Django 1.2 promet plusieurs autres améliorations majeures touchant notamment à l'administration, le logging, l'internationalisation, le moteur de template et les tests. La sortie est prévue pour mars 2010, ce qui laisse du temps pour que la gestion multi-db soit éprouvée et stabilisée par la communauté, sans doute avide de l'essayer.

• Documentation officielle
• Progression de la version 1.2 (roadmap)
• http://sqlrelay.sourceforge.net/
• http://forge.mysql.com/wiki/MySQL_Proxy