Todavía soy bastante nuevo en Python y Django, así que tengo una situación que no estoy seguro de cómo resolver.
El problema principal es que en la implementación de mi código para el desarrollo, la implementación falla, para la etapa o la producción, pasa.
Trabajé en un problema en el que tenía que colocar algunas columnas en una tabla en nuestra aplicación. Después de realizar los cambios, implementé en desarrollo y pedí una revisión del código. En la revisión del código, se sugirió que cambiara el nombre del archivo de migración a algo más descriptivo en lugar de simplemente dejarlo 0018_auto_.
Hice ese cambio y lo desplegué en desarrollo y etapa. Dev falló (cuando esperaba que tuviera éxito) porque se vio el nuevo nombre y django intentó eliminar columnas que ya no existen. En etapa, nunca se cambió el nombre y las columnas se eliminaron por primera vez usando ese nuevo nombre del archivo.
Así que el escenario se despliega muy bien.
¿Cómo resuelvo este error en el desarrollador para que reconozca que esta migración ya tuvo lugar?
¡Gracias!
Si está 100% seguro de que el único cambio realizado para 0018 fue el nombre del archivo y que es la última migración de su aplicación, puede hacer lo siguiente:
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18 python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename Esto mantendrá los cambios que están presentes en 0018 y solo aplicará los cambios al nombre del archivo.
Django construye una tabla llamada djang_migrations que realiza un seguimiento de las migraciones que se han aplicado. Si luego cambia el nombre de un archivo de migración, aparecerá como si esa migración no se hubiera ejecutado.
Puede cambiar el nombre de la migración en la tabla django_migrations de su entorno de desarrollo con:
UPDATE django_migrations SET name = ' 0018_new_name ' WHERE app = '%%%name_of_the_app' AND name = '0018_auto_' donde 0018_new_name es el nuevo nombre del archivo de migración.
Al actualizar este nombre, Django ahora debería considerar el nuevo archivo de migración como hecho.
¡Todas estas fueron excelentes respuestas y sin duda ayudarán a otros ahora y en el futuro!
Intenté todas estas respuestas pero solo una cosa funcionó. ¡El camino largo!
Para una visibilidad completa ( esto funcionó localmente y lo entiendo, falso ahora en la práctica, ¡gracias @brian-destura!):
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18 python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filenameSin embargo, en la implementación a través de gitlab, nuestra aplicación django / zappa simplemente no quería implementarse con éxito (incluso con muchas soluciones diferentes probadas).
Al final, la única forma de solucionar el problema fue actualizar el archivo de migración 0018 para volver a agregar todos esos campos, deshacer los cambios en los modelos y serializadores, y volver a implementar en desarrollo.
Después de eso, revierta todos esos cambios, incluido el archivo de migración, y vuelva a implementarlo en dev.
Probablemente haya una manera más fácil de hacer esto, pero con todos aquellos con más conocimiento de back-end para las vacaciones (soy un front-end originalmente con más conocimientos/proyectos de back-end durante el año pasado), estaba muy feliz de resolver y publicar mis cambios. .
Gracias a ustedes por algunas cosas para probar, ideas y conocimiento definitivo que podría usar para crear esta, ¡mi propia solución de largo aliento!