Solución:
Bueno, la documentación es muy clara al respecto.
–inicial falsa
Permite que Django omita la migración inicial de una aplicación si ya existen todas las tablas de la base de datos con los nombres de todos los modelos creados por todas las operaciones CreateModel en esa migración. Esta opción está pensada para su uso cuando se ejecutan por primera vez migraciones en una base de datos que ya existía antes del 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, bueno aquí está
solo es seguro de usar si está seguro de que su esquema existente coincide con lo que se registró en su migración inicial.
–falso
Le dice a Django que marque las migraciones como aplicadas o no aplicadas, pero sin ejecutar realmente el SQL para cambiar el esquema de su base de datos.
Esto está destinado a 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
Tenga en cuenta que el uso de –fake corre el riesgo de poner la tabla de estado de migración en un estado en el que se necesitará una recuperación manual para que las migraciones se ejecuten correctamente.
Esta respuesta es válida no solo para las versiones 1.8+ de django, sino también para otras versiones.
editar noviembre de 2018: a veces veo respuestas aquí y en otros lugares que sugieren que debería eliminar su databae. Eso casi nunca es lo correcto. Si abandona su base de datos, perderá todos sus datos.
@ 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.
Suponga 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 Viene muy bien.
los --fake-initial forzará 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. Sin embargo, tenga en cuenta que se ejecutarán todas las migraciones que no creen tablas (sino que modifiquen las tablas existentes).
Por el contrario, si tiene un proyecto existente con archivos de migración y desea restablecer el historial de migraciones existentes, entonces --fake se utiliza habitualmente.
Respuesta corta
-
--fakeno aplicar la migración -
--fake-initialpodría, o podría no aplicar la migración
Respuesta más larga:
--fake: Django mantiene una tabla llamada django_migrations para saber qué migraciones ha aplicado en el pasado, para evitar que las vuelva a aplicar accidentalmente. Todos --fake lo que hace es insertar el nombre del archivo de migración en esa tabla, sin realmente correr la migración. Esto es útil si primero cambió manualmente el esquema de la base de datos y luego los modelos, y desea omitir las acciones de django. Sin embargo, durante ese paso estás solo, así que ten cuidado de no terminar en un estado inconsistente.
--fake-initial: depende del estado de la base de datos
-
todas las mesas ya existen en la base de datos: en ese caso, funciona como
--fake. Solo los nombres de las tablas están verificadas, no su esquema real, así que, nuevamente, tenga cuidado - ninguna de las mesas ya existen en la base de datos: en ese caso, funciona como una migración normal
- algo de la mesa ya existe: obtiene un error. Se supone que eso no debe suceder, o usted se ocupa de la base de datos o django lo hace.
Tenga en cuenta que, --fake-initial solo se tiene en cuenta si el archivo de migración tiene initial=True en su clase, de lo contrario, la bandera se ignora. Además, este es el único uso documentado de initial=True en migraciones.