Django: Cambiando de DB Engine
— 959 hitsNormalmente las especificaciones de un entorno de desarrollo y las de un entorno en producción suelen ser bastante diferentes. Quizás en el primero buscas la comodidad mientras que cuando se hace el deploy a producción priman otras cosas. Este suele ser el caso del motor de base de datos cuando trabajas con Django.
Durante el proceso de desarrollo es muy cómodo utilizar sqlite porque no requiere de ningún servidor adicional y está soportado de base en Django (builtin). Es posible que una vez acabado el desarrollo queramos cambiar a otro SGBD "de verdad" como pueden ser MySQL o PostgreSQL.
Lo que podría suponer un quebradero de cabeza en otras arquitecturas, en nuestro caso utilizando dumpdata y loaddata, se reduce a las siguientes tres lineas:
$ python manage.py dumpdata --indent=4 --format=json > fixtures.json $ scp fixtures.json user@remote:/path/project/ (remote)$ python manage.py loaddata fixtures.json
En la primera usamos dumpdata para hacer un dumpeado de todos los datos de la aplicación (sqlite) en formato json, posteriormente pasamos ese archivo al entorno de producción (en este caso pongamos de ejemplo a otro servidor) y allí finalmente (con el conector apuntando al nuevo gestor) ejecutamos el loaddata para insertar los datos.
Et voilà!
Comentarios
Buen post, como siempre, pero ojo con lo del sqlite built-in, porque si bien las versiones recientes de Python tienen ese soporte, es posible que el sistema de paquetes del sistema operativo que estés utilizando lo tenga separado en un paquete adicional, separado del paquete de python.
La advertencia de Wu es buena. Además sqlite puede "ocultar" algunos fallos que en otros SGBD sí pueden darnos una sorpresa. Por ejemplo: diferencias con charsets (igual no es tan problema si vas con UTF-8).
De hecho es una de las limitaciones de correr los tests de Django con sqlite, que hay cosas que no puedes probar si no es con la SGBD que trabajas en producción :S