En mi aplicación Django, quiero agregar un par de campos a mis modelos existentes y posiblemente crear una nueva clase. Solo quiero probar la nueva función y aprobar si funciona.
Puedo revertir el código usando git fácilmente. Pero si realizo makemigrations + migrate , mi base de datos MySQL cambiará y la reversión de los cambios parecerá una eliminación manual de tablas y volver a un estado anterior usando un comando como django-admin migrate [app_label] [migration_name] (En algunos casos parece realmente engorroso, ejemplo ).
Me pregunto si existe alguna práctica segura para intentar manipular la base de datos y revertirla a su estado inicial de manera segura.
Solución probable #1:
Puede utilizar la base de datos de prueba que se crea al usar django.test.TestCase :
Las pruebas que requieren una base de datos (es decir, pruebas modelo) no utilizarán su base de datos "real" (de producción). Se crean bases de datos separadas y en blanco para las pruebas.
Cree algunas pruebas unitarias para su proyecto y realice sus migraciones (sin migrar a su base de datos de producción, solo mantenga las migraciones). Después:
Si la base de datos no existe, primero se creará. Cualquier migración también se aplicará para mantenerlo actualizado.
Por lo general, la base de datos se destruye al final de las pruebas, pero puede conservarla entre ejecuciones:
Puede evitar que las bases de datos de prueba se destruyan utilizando la opción
test --keepdb. Esto preservará la base de datos de prueba entre ejecuciones.
Con este truco, puede probar cada migración que realiza en una base de datos falsa y cuando finaliza su modelo y tiene todo el historial de migraciones completo, puede migrate a su base de datos de producción.
Solución probable #2:
Puede hacer una copia de su base de datos como sugiere @albar y tenerla como respaldo mientras trabaja en sus nuevas migraciones.
Rompe cosas tanto como quieras y cuando hayas terminado, reemplaza la base de datos "maltratada" con tu copia de seguridad y aplica tu historial de migración.