migraciones makemigrations eliminar python django django-1.7 django-migrations

python - eliminar - Django 1.7-makemigrations no detecta cambios



eliminar migraciones django (23)

¿ schemamigration my_app --initial después de cambiar el nombre de la carpeta de migración anterior? Intentalo. Podría funcionar. Si no, intente recrear la base de datos y hacer syncdb + migrate. Funcionó para mí ...

Como dice el título, parece que no puedo lograr que las migraciones funcionen.

La aplicación originalmente era inferior a 1.6, así que entiendo que las migraciones no estarán allí inicialmente, y de hecho si ejecuto python manage.py migrate obtengo:

Operations to perform: Synchronize unmigrated apps: myapp Apply all migrations: admin, contenttypes, auth, sessions Synchronizing apps without migrations: Creating tables... Installing custom SQL... Installing indexes... Running migrations: No migrations to apply.

Si realizo un cambio en cualquier modelo en myapp , todavía dice no migrado, como se esperaba.

Pero si ejecuto python manage.py makemigrations myapp obtengo:

No changes detected in app ''myapp''

No parece importar qué o cómo ejecuto el comando, nunca detecta que la aplicación tenga cambios ni agrega ningún archivo de migración a la aplicación.

¿Hay alguna forma de forzar una aplicación sobre las migraciones y esencialmente decir "Esta es mi base para trabajar" o algo así? ¿O me estoy perdiendo algo?

Mi base de datos es una de PostgreSQL si eso ayuda en absoluto.

Agregando esta respuesta porque solo este método me ayudó.

makemigrations carpeta de migrations ejecute makemigrations y migrate .
Todavía dijo: No hay migraciones para aplicar.

Fui a migrate carpeta y abrí el último archivo creado,
comentar la migración que quería (se detectó e ingresó allí)
y ejecutar migrate nuevo.

Esto básicamente edita el archivo de migraciones manualmente.
Hazlo solo si entiendes el contenido del archivo.

Agregando mi 2c, ya que ninguna de estas soluciones funcionó para mí, pero esto sí ...

Acababa de ejecutar manage.py squashmigrations y manage.py squashmigrations las antiguas migraciones (tanto los archivos como las líneas en la tabla de la base de datos django.migrations).

Esto dejó una línea como esta en el último archivo de migración:

replaces = [(b''my_app'', ''0006_auto_20170713_1735''), (b''my_app'', ''0007_auto_20170713_2003''), (b''my_app'', ''0008_auto_20170713_2004'')]

Esto aparentemente confundió a Django y causó un comportamiento extraño: ejecutar manage.py makemigrations my_app recrearía la migración inicial como si no existiera. Quitar la línea replaces... solucionó el problema.

Agregué esta respuesta porque ninguno de los otros disponibles anteriormente funcionó para mí.

En mi caso sucedía algo aún más extraño ( versión Django 1.7 ), en mi models.py tenía una línea "extra" al final de mi archivo (era una línea en blanco) y cuando python manage.py makemigrations el python manage.py makemigrations comando el resultado fue: "no se detectaron cambios".

Para solucionar esto, eliminé esta "línea en blanco" que estaba al final de mi archivo models.py y ejecuté el comando otra vez, todo se solucionó y todos los cambios realizados en models.py se detectaron.

Asegúrate de que tu modelo no sea abstract . De hecho, cometí ese error y me tomó un tiempo, así que pensé en publicarlo.

De acuerdo con @furins. Si todo parece estar en orden y aún surge este problema, revise si hay algún método de propiedad con el mismo título que el atributo que está tratando de agregar en la clase de Modelo.

  1. Elimine el método con el mismo nombre que el atributo que está agregando.
  2. manage.py makemigrations my_app
  3. manage.py migrate my_app
  4. Agrega los métodos de vuelta.

Desea verificar settings.py en la lista INSTALLED_APPS y asegurarse de que todas las aplicaciones con modelos estén enumeradas allí.

Ejecutar makemigrations en la carpeta del proyecto significa que buscará actualizar todas las tablas relacionadas con todas las aplicaciones incluidas en settings.py para el proyecto. Una vez que lo incluya, makemigrations incluirá automáticamente la aplicación (esto ahorra mucho trabajo, por lo que no tiene que ejecutar makemigrations app_name para cada aplicación en su proyecto / sitio).

En caso de que tenga un campo específico que no se identifique por makemigrations: verifique dos veces si tiene una propiedad con el mismo nombre.

ejemplo:

field = django.db.models.CharField(max_length=10, default = '''', blank=True, null=True) # ... later @property def field(self): pass

la propiedad "sobrescribirá" la definición del campo para que los cambios no sean identificados por makemigrations

Esto es una especie de error estúpido, pero tener una coma adicional al final de la línea de declaración de campo en la clase de modelo hace que la línea no tenga ningún efecto.

Sucede cuando copias y pegas la definición. de la migración, que a su vez se define como una matriz.

Aunque tal vez esto ayudaría a alguien :-)

Esto puede suceder debido a las siguientes razones:

  1. No agregó la aplicación en la lista INSTALLED_APPS en settings.py (Debe agregar el nombre de la aplicación o la ruta de puntos a la subclase de AppConfig en apps.py en la carpeta de la aplicación, dependiendo de la versión de django que esté usando) . Consulte la documentación: INSTALLED_APPS
  2. No tiene una carpeta de migrations dentro de esas aplicaciones. (Solución: solo crea esa carpeta).
  3. No tiene el archivo __init__.py dentro de la carpeta de migrations de esas aplicaciones. (Solución: solo crea un archivo vacío con el nombre __init__.py )
  4. No tiene un archivo __init__.py dentro de la carpeta de la aplicación. (Solución: solo crea un archivo vacío con el nombre __init__.py )
  5. No tienes un archivo models.py en la aplicación
  6. Su clase Python (se supone que es un modelo) en models.py no hereda django.db.models.Model
  7. Tiene algún error semántico en la definición de modelos en models.py

Nota: Un error común es agregar la carpeta de migrations en el archivo .gitignore . Cuando se clona desde el repositorio remoto, la carpeta de migrations y / o los archivos __init__.py en el repositorio local. Esto causa un problema.

Sugiero ignorar los archivos de migración agregando las siguientes líneas al archivo .gitignore

*/migrations/* !*/migrations/__init__.py

La respuesta está en esta publicación de , por cdvv7788 Migrations in Django 1.7

Si es la primera vez que está migrando esa aplicación, debe usar:

manage.py makemigrations myappname Una vez que haces eso, puedes hacer:

manage.py migrate Si tenía su aplicación en la base de datos, modificó su modelo y no actualiza los cambios en makemigrations, probablemente aún no lo haya migrado. Cambie su modelo a su forma original, ejecute el primer comando (con el nombre de la aplicación) y migre ... lo falsificará. Una vez que lo haga, vuelva a colocar los cambios en su modelo, ejecute makemigrations y migre de nuevo, y debería funcionar.

Estaba teniendo exactamente el mismo problema y hacer lo anterior funcionó perfectamente.

Había movido mi aplicación django a cloud9 y por alguna razón nunca capté la migración inicial.

Las personas como yo a las que no les gustan las migraciones pueden seguir los pasos a continuación.

  1. Eliminar los cambios que desea sincronizar.
  2. Ejecute python manage.py makemigrations app_label para la migración inicial.
  3. Ejecute python manage.py migrate para crear tablas antes de realizar cambios.
  4. Pegue los cambios que elimine en el primer paso.
  5. Ejecutar 2. y 3. pasos.

Si confundió alguno de estos pasos, lea los archivos de migración. Cámbielos para corregir su esquema o elimine los archivos no deseados, pero no olvide cambiar la parte de dependencias del siguiente archivo de migración;)

Espero que esto ayude a alguien en el futuro.

Lo siguiente funcionó para mí:

  1. Agregue el nombre de la aplicación a settings.py
  2. use ''python manage.py makemigrations''
  3. use ''python manage.py migrate''

Funcionó para mí: Python 3.4, Django 1.10

Mi solución no estaba cubierta aquí, así que la estoy publicando. Había estado usando syncdb para un proyecto, solo para ponerlo en funcionamiento. Luego, cuando traté de comenzar a usar las migraciones de Django, al principio las fingía y luego decía que estaban "OK", pero no sucedía nada en la base de datos.

Mi solución fue simplemente eliminar todos los archivos de migración para mi aplicación, así como los registros de la base de datos para las migraciones de la aplicación en la tabla django_migrations .

Entonces acabo de hacer una migración inicial con:

./manage.py makemigrations my_app

seguido por:

./manage.py migrate my_app

Ahora puedo hacer migraciones sin problemas.

Ok, parece que me perdí un paso obvio, pero publicando esto en caso de que alguien más haga lo mismo.

Al actualizar a 1.7, mis modelos se convirtieron en no administrados ( managed = False ) - Los tenía como True antes, pero parece que se revirtieron.

Al eliminar esa línea (de manera predeterminada a True) y luego ejecutar makemigrations se makemigrations inmediatamente un módulo de migración y ahora está funcionando. makemigrations no funcionará en tablas no administradas (lo cual es obvio en retrospectiva)

Quizás esto ayudará a alguien. Estaba usando una aplicación anidada. project.appname y en realidad tenía project y project.appname en INSTALLED_APPS. Al eliminar el proyecto de INSTALLED_APPS, se permitieron detectar los cambios.

Quizás esto ayudará a alguien.

He eliminado mi models.py y makemigrations esperado makemigrations para crear sentencias DeleteModel .

¡Recuerde eliminar los *.pyc !

Recientemente actualicé Django de 1.6 a 1.8 y tenía pocas aplicaciones y migraciones para ellos. schemamigrations south y schemamigrations para crear migraciones en Django 1.6, que se eliminó en Django 1.8.

Cuando agregué nuevos modelos después de la actualización, el comando makemigrations no makemigrations ningún cambio. Y luego probé la solución sugerida por @drojf (primera respuesta), funcionó bien, pero no se pudo aplicar la migración inicial falsa ( python manage.py --fake-initial ). Estaba haciendo esto ya que mis tablas (tablas antiguas) ya estaban creadas.

Finalmente, esto funcionó para mí, eliminó nuevos modelos (o cambios de modelo) de models.py y luego tuvo que eliminar (o cambiar el nombre de la copia de seguridad de seguridad) la carpeta de migraciones de todas las aplicaciones y ejecutar python manage.py makemigrations para todas las aplicaciones, luego Python manage.py python manage.py migrate --fake-initial . Funcionó como por arte de magia. Una vez que se crea la migración inicial para todas las aplicaciones y la migración inicial falsa, se agregan nuevos modelos y se sigue el proceso regular de makemigrations y se migra en esa aplicación. Los cambios se detectaron ahora y todo fue bien.

Solo pensé en compartirlo aquí, si alguien enfrenta el mismo problema (tener schemamigrations of south para sus aplicaciones), podría ayudarles :)

Si está cambiando desde una aplicación existente que creó en django 1.6, entonces necesita hacer un pre-paso (como me enteré) que figura en la documentación:

python manage.py makemigrations your_app_label

La documentación no hace obvio que necesite agregar la etiqueta de la aplicación al comando, ya que lo primero que le indica que haga es python manage.py makemigrations que fallará. La migración inicial se realiza cuando crea su aplicación en la versión 1.7, pero si proviene de 1.6 no se hubiera llevado a cabo. Consulte ''Agregar migración a aplicaciones'' en la documentación para obtener más detalles.

Tal vez eso pueda ayudar a alguien, tuve el mismo problema.

Ya he creado dos tablas con la clase de serializador y las vistas. Entonces cuando quise actualizar, tuve este error.

Seguí estos pasos:

  1. Hice la aplicación ./manage.py makemigrations app
  2. ./manage.py migrate
  3. Borré ambas tablas de mis models.py
  4. Borré todas las referencias a mis tablas de serializador y clase de vista.
  5. Ejecuté los pasos 1 y 2 .
  6. Recuperé mis cambios solo en el models.py
  7. Ejecuté nuevamente el paso 5 .
  8. Restaure todos mis cambios.

Si trabajas con Pycharm, la historia local es muy útil.

Tal vez sea demasiado tarde, pero ¿trataste de tener una carpeta de migrations en tu aplicación con un archivo __init__.py ?

Tuve el mismo problema al tener que ejecutar makemigrations dos veces y todo tipo de comportamiento extraño. Resultó que la raíz del problema era que estaba usando una función para establecer las fechas predeterminadas en mis modelos, por lo que migrations detectaba un cambio cada vez que ejecutaba makemigrations. La respuesta a esta pregunta me puso en el camino correcto: evitar migraciones para volver a crear el campo de fecha

./manage makemigrations ./manage migrate

Las migraciones rastrean los cambios en la base de datos, por lo que si cambia de no administrado a administrado, deberá asegurarse de que su tabla de base de datos esté actualizada en relación con el modelo con el que está trabajando.

Si todavía está en el modo dev, personalmente decidí eliminar los archivos de migración en mi IDE, así como en la tabla django_migrations relacionada con mi Modelo y volver a ejecutar el comando anterior.

RECUERDE: si tiene una migración que termina con _001 en su IDE y _003 en su base de datos. Django solo verá si tienes una migración que termine con _004 para que se actualice algo.

Los 2 (migraciones de código y db) están vinculados y funcionan en tándem.

Feliz codificación.