manage - --fake-initial vs--fake en la migración de Django?

migrations django command

Question

¿Cuál es la diferencia entre --fake-initial y --fake en las migraciones de Django? ¿Cuáles son los peligros de usar migraciones falsas? ¿Cualquiera sabe? Muchas gracias a todos.

Estoy usando django 1.10

Answer 1

@ e4c5 ya dio una respuesta sobre esta pregunta, pero me gustaría agregar una cosa más sobre cuándo usar --fake y --fake-initial .

Supongamos que tiene una base de datos de producción y desea utilizarla para el desarrollo y aplicar migraciones sin destruir los datos. En ese caso --fake-initial es muy útil.

La --fake-initial obligará a Django a mirar sus archivos de migración y básicamente omitir la creación de tablas que ya están en su base de datos. Tenga en cuenta, sin embargo, que se ejecutarán las migraciones que no crean tablas (sino que modifican las tablas existentes).

A la inversa, si tiene un proyecto existente con archivos de migración y desea restablecer el historial de migraciones existentes, generalmente se usa --fake .

Answer 2

Bueno, la documentación es muy clara al respecto.

--fake-initial

Permite a Django omitir la migración inicial de una aplicación si ya existen todas las tablas de base de datos con los nombres de todos los modelos creados por todas las operaciones de CreateModel en esa migración. Esta opción está diseñada para ser utilizada cuando se ejecutan migraciones por primera vez en una base de datos que preexistía el uso de migraciones. Sin embargo, esta opción no comprueba el esquema de base de datos coincidente más allá de los nombres de tabla coincidentes

Estabas preguntando por los riesgos, pues aquí está.

solo es seguro de usar si está seguro de que su esquema existente coincide con lo registrado en su migración inicial.

--falso

Le dice a Django que marque las migraciones como aplicadas o no, pero sin ejecutar realmente el SQL para cambiar el esquema de su base de datos.

Esto está destinado a los usuarios avanzados para manipular el estado de migración actual directamente si están aplicando cambios manualmente;

Una vez más, los riesgos se destacan claramente

se le advierte que al usar --fake se corre el riesgo de poner la tabla de estado de migración en un estado donde se necesitará la recuperación manual para que las migraciones se ejecuten correctamente.

Esta respuesta es válida no solo para las versiones de django 1.8+ sino también para otras versiones.

Ed. de noviembre de 2018: a veces veo respuestas aquí y en otros lugares que sugieren que debería abandonar su base de datos. Eso casi nunca es lo correcto. Si sueltas tu base de datos pierdes todos tus datos.