Despliegue de Django: Manejo de datos en la base de datos

Question

Ahora estoy usando git para la implementación de Django, lo que me parece satisfactorio. Mi único problema sigue siendo cómo manejar los datos en la base de datos correctamente. P.ej. A menudo necesito editar los datos provenientes del sitio de producción localmente y volver a poner los datos en el sitio de producción (¡tenga en cuenta que estoy hablando de cambios de datos y no de migraciones de esquemas!). Creo que el flujo de trabajo debe ser similar a lo siguiente: Volcar datos en el sitio de producción> descargar datos> cargar datos en db> realizar cambios localmente> volcar datos> crear diferencias para datos> cargar diff & aplicar cambios en el sitio de producción.

Para mí es importante sería que esto también funciona para los cambios en las filas de bases de datos existentes, supresiones, etc ...

Así que si comienzo a experimentar con el que por mi cuenta: 1. ¿Funcionará con cualquiera de las ofertas de formato de volcado de datos? 2. ¿Alguien más trabaja de esa manera, tal vez ya tenga algunas soluciones de script (de tela) listas para eso?

Answer 1

Las tablas que deseo volcar/cambiar/restaurar son bastante pequeñas y son de solo lectura a través de la interfaz pública. El siguiente método se utiliza:

1. Los datos se vuelcan con el comando dumpdata ./manage.py en el servidor.
2. A continuación, el archivo de resultados se compromete a VCS en el servidor.
3. Extraigo los cambios y ejecuto ./manage.py loaddata.
4. Después de realizar los cambios ./manage dumpdata se ejecuta localmente.
5. El archivo de resultados se compromete a VCS y empujado hacia atrás con el servidor
6. comando ./manage loaddata se ejecuta en el servidor

Esto puede ser automatizado con la tela, por ejemplo

1 + 2 + 3 = fab dump_data:cities, 4 + 5 + 6 = fab push_data:cities

Diffs se producen internamente por VCS. Este enfoque no funcionará para todo, pero lo encontré útil para casos simples.

Answer 2

1) Entiendo que no está hablando de la migración de esquemas. Sin embargo, hay una migración de datos . He usado South para hacer el tipo de cambios en los datos de producción que ha descrito. Puede valer la pena investigarlo.

2) En mi humilde opinión aplicar una diferencia no es la mejor manera de modificar volcados de base de datos. Diff y merge son más aplicables al código fuente/texto que a los volcados de bases de datos. Dicho esto, tengo curiosidad por saber si alguien ha realizado con éxito diff/patch/merge en los volcados de bases de datos.

Answer 3

Si el back-end de su base de datos es SQL Server, Red-Gate tiene una herramienta de comparación de datos que puede usar. Sin embargo, no estoy seguro de qué herramientas están disponibles fuera del mundo del Servidor SQl.

Answer 4

Si descarga> modificar> cargar un volcado completo, tiene que estar listo para la pérdida de datos. Cualquier dato que se cree/modifique durante la producción mientras descarga, modifica o carga datos modificados se perderá.

mejores prácticas para evitar que si se puede modificar datos en la base de datos de producción sería:

1. crear secuencias de comandos SQL basado en las modificaciones locales y ejecutarlo en la base de datos de producción,
2. crear vista de gestión de cambios de datos y ejecutarlo en el servidor web de producción

o, si no puede modificar los datos en la base de datos de producción:

• crear volcado, descargar y cargar de forma local,
• modificar los datos localmente,
• crear vertedero local,
• comparar volcado remoto con vertedero local y create volcado solamente contiene modificado/añadido registros,
• ha subido y se carga

carga y carga parcial en este caso sería mucho más rápido pero te tiene que manejar deleciones de otra manera.