Django - makemigrations - No se detectaron cambios

Estaba tratando de crear migraciones dentro de una aplicación existente usando el comando makemigrations pero muestra "No se detectaron cambios".

Por lo general, creo nuevas aplicaciones usando el startappcomando pero no lo usé para esta aplicación cuando la creé.

Después de la depuración, descubrí que no está creando migración porque migrationsfalta una aplicación en el paquete / carpeta.

¿Sería mejor si crea la carpeta si no está allí o me falta algo?

Para crear migraciones iniciales para una aplicación, ejecute makemigrationsy especifique el nombre de la aplicación. Se creará la carpeta de migraciones.

./manage.py makemigrations <myapp>

Su aplicación debe incluirse INSTALLED_APPSprimero (dentro de settings.py).

Mi problema (y la solución) era aún diferente de los descritos anteriormente.

No estaba usando el models.pyarchivo, pero creé un modelsdirectorio y creé el my_model.pyarchivo allí, donde puse mi modelo. Django no pudo encontrar mi modelo, por lo que escribió que no hay migraciones para aplicar.

Mi solución fue: en el my_app/models/__init__.pyarchivo agregué esta línea: from .my_model import MyModel

Hay varias razones posibles para que django no detecte qué migrar durante el makemigrationscomando.

1. carpeta de migración Necesita un paquete de migraciones en su aplicación.
2. INSTALLED_APPS Necesita que su aplicación se especifique en el INSTALLED_APPS.dict
3. Verbosity comienza por correr makemigrations -v 3para verbosity. Esto podría arrojar algo de luz sobre el problema.
4. INSTALLED_APPSRuta completa En se recomienda especificar la ruta de configuración de la aplicación del módulo completo 'apply.apps.MyAppConfig'
5. - configuraciones que tal vez desee asegurarse de que esté configurado el archivo de configuración correcto:manage.py makemigrations --settings mysite.settings
6. especifique el nombre de la aplicación, ponga explícitamente el nombre de la aplicación manage.py makemigrations myapp, lo que reduce las migraciones solo para la aplicación y lo ayuda a aislar el problema.

7. metacomprobación del modelo que tiene el derecho app_labelen su meta meta

8. Debug django debug django core script. El comando makemigrations es bastante sencillo. Aquí se explica cómo hacerlo en pycharm . cambie la definición de su script en consecuencia (ej . makemigrations --traceback myapp:)

Múltiples bases de datos:

• Db Router cuando se trabaja con django db router, la clase de enrutador (su clase de enrutador personalizada) necesita implementar el allow_syncdbmétodo.

makemigrations siempre crea migraciones para cambios de modelo, pero si allow_migrate () devuelve False,

He leído muchas respuestas a esta pregunta, a menudo afirmando que simplemente se ejecuta makemigrationsde alguna otra manera. Pero para mí, el problema estaba en la Metasubclase de modelos.

Tengo una configuración de la aplicación que dice label = <app name>(en el apps.pyarchivo, al lado models.py, views.pyetc.). Si por casualidad su metaclase no tiene la misma etiqueta que la etiqueta de la aplicación (por ejemplo, porque está dividiendo una aplicación demasiado grande en varias), no se detectarán cambios (y ningún mensaje de error útil). Entonces en mi clase de modelo tengo ahora:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

Ejecutando Django 1.10 aquí.

Es un comentario pero probablemente debería ser una respuesta.

Asegúrese de que el nombre de su aplicación esté en settings.py, de lo INSTALLED_APPScontrario, no importa lo que haga, no se ejecutarán las migraciones.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

Entonces corre:

./manage.py makemigrations blog

Tuve otro problema no descrito aquí, que me volvió loco.

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

Tuve un ',' al final en una línea quizás de copiar y pegar. La línea con is_dumb no creó un modelo de migración con './manage.py makemigrations' pero tampoco arrojó un error. Después de eliminar el ',' funcionó como se esperaba.

Así que tenga cuidado cuando copie y pegue :-)

A veces hay cuando ./manage.py makemigrationses superior a ./manage.py makemigrations <myapp>porque puede manejar ciertos conflictos entre aplicaciones.

Esas ocasiones ocurren en silencio y toma varias horas swearingentender el significado real del No changes detectedmensaje temido .

Por lo tanto, es una opción mucho mejor utilizar el siguiente comando:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>

Había copiado una tabla desde fuera de django y la clase Meta por defecto era "gestionado = falso". Por ejemplo:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

Al cambiar manged a True, makemigrations comenzó a recoger cambios.

1. Asegúrese de que su aplicación se mencione en instalted_apps en settings.py
2. Asegúrese de que la clase de modelo amplía los modelos.

Resolví ese problema haciendo esto:

1. Borre el archivo "db.sqlite3". El problema aquí es que su base de datos actual se borrará, por lo que tendrá que rehacerla nuevamente.
2. Dentro de la carpeta de migraciones de su aplicación editada, borre el último archivo actualizado. Recuerde que el primer archivo creado es: "0001_initial.py". Por ejemplo: hice una nueva clase y la registré mediante el procedimiento "makemigrations" y "migrate", ahora se creó un nuevo archivo llamado "0002_auto_etc.py"; Bórralo.
3. Vaya a la carpeta " pycache " (dentro de la carpeta de migraciones) y borre el archivo "0002_auto_etc.pyc".
4. Finalmente, vaya a la consola y use "python manage.py makemigrations" y "python manage.py migrate".

Olvidé poner argumentos correctos:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

en models.py y luego comenzó a caer ese molesto

No se detectaron cambios en la aplicación 'myApp'

Otra posible razón es si tenía algunos modelos definidos en otro archivo (no en un paquete) y no lo ha mencionado en ningún otro lugar.

Para mí, simplemente agregar from .graph_model import *a admin.py(dónde graph_model.pyestaba el nuevo archivo) solucionó el problema.

Mi problema era mucho más simple que las respuestas anteriores y probablemente una razón mucho más común siempre que su proyecto ya esté configurado y funcionando. En una de mis aplicaciones que había estado funcionando durante mucho tiempo, las migraciones parecían inestables, así que a toda prisa hice lo siguiente:

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

Que?

Por error, también eliminé todos los __init__.pyarchivos :( - Todo estaba funcionando nuevamente después de entrar y:

touch ads1/migrations/__init__.py

Para cada una de mis aplicaciones, makemigrationsfuncionó nuevamente.

Resulta que había creado manualmente una nueva aplicación copiando otra y olvidé ponerla __init__.pyen la migrationscarpeta y eso me confinó que todo estaba inestable, lo que empeoró mi situación con rm -rlo descrito anteriormente.

Espero que esto ayude a alguien a maldecir el error "No se detectaron cambios" durante unas horas.

La solución es que debe incluir su aplicación en INSTALLED_APPS.

Lo perdí y encontré este mismo problema.

después de especificar que la migración del nombre de mi aplicación se realizó correctamente

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

tenga en cuenta que mencioné tableros en último lugar, que es el nombre de mi aplicación.

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

asegúrese de 'blog.apps.BlogConfig', (esto está incluido en su settings.py para hacer las migraciones de su aplicación)

luego ejecute el blog python3 manage.py makemigrations o el nombre de su aplicación

Un problema muy tonto que puede tener también es definir dos class Metaen su modelo. En ese caso, cualquier cambio en el primero no se aplicará cuando se ejecute makemigrations.

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

Sé que esta es una vieja pregunta, pero luché con este mismo problema todo el día y mi solución fue simple.

Tenía mi estructura de directorios algo parecido a ...

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

Y dado que todos los otros modelos hasta el que tuve un problema se importaban en otro lugar que terminó importando desde el main_appque se registró en el INSTALLED_APPS, tuve la suerte de que todos funcionaran.

Pero como solo agregué cada uno appde ellos INSTALLED_APPSy no app_sub*cuando finalmente agregué un nuevo archivo de modelos que no se importó EN NINGÚN OTRO LUGAR, Django lo ignoró por completo.

Mi solución fue agregar un models.pyarchivo al directorio base de cada uno appasí ...

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

y luego agregue from apps.app.app_sub1 import *y así sucesivamente a cada uno de los archivos de appnivel models.py.

Bleh ... esto me tomó TANTO tiempo en descubrir y no pude encontrar la solución en ningún lado ... Incluso fui a la página 2 de los resultados de Google.

¡Espero que esto ayude a alguien!

Tuve un problema similar con django 3.0, de acuerdo con la sección de migraciones en la documentación oficial , ejecutar esto fue suficiente para actualizar la estructura de mi tabla:

python manage.py makemigrations
python manage.py migrate

Pero el resultado siempre fue el mismo: 'no se detectó ningún cambio' sobre mis modelos después de ejecutar el script 'makemigrations'. Tuve un error de sintaxis en models.py en el modelo que quería actualizar en db:

field_model : models.CharField(max_length=255, ...)

en vez de:

field_model = models.CharField(max_length=255, ...)

Resolviendo este estúpido error, con esos comandos la migración se realizó sin problemas. Quizás esto ayude a alguien.

Usted debe agregar polls.apps.PollsConfiga INSTALLED_APPSensetting.py

En mi caso olvidé insertar los argumentos de clase

Incorrecto:

class AccountInformation():

Correcto

class AccountInformation(models.Model):

En mi caso, primero agregué un campo al modelo, y Django dijo que no hay cambios.

Entonces decidí cambiar el "nombre de la tabla" del modelo, makemigrations funcionó. Luego cambié el nombre de la tabla al valor predeterminado, y el nuevo campo también estaba allí.

Hay un "error" en el sistema de migración de django, a veces no ve el nuevo campo. Podría estar relacionado con el campo de fecha.

La posible razón podría ser la eliminación del archivo db existente y la carpeta de migraciones, puede usar python, manage.py makemigrations <app_name>esto debería funcionar. Una vez enfrenté un problema similar.

Un caso más y una solución más:

Agregué un campo booleano, y al mismo tiempo agregué un @property haciendo referencia a él, con el mismo nombre (doh). Comentó la propiedad y la migración ve y agrega el nuevo campo. Renombrado la propiedad y todo está bien.

Si tiene el managed = Truemodelo Meta en su modelo, debe eliminarlo y realizar una migración. Luego ejecute las migraciones nuevamente, detectará las nuevas actualizaciones.

Al agregar nuevos modelos a la aplicación django api y ejecutar python manage.py makemigrationsla herramienta, no detectó ningún modelo nuevo.

Lo extraño fue que los viejos modelos fueron elegidos makemigrations, pero esto se debió a que estaban referenciados en la urlpatternscadena y la herramienta los detectó de alguna manera. Así que vigila ese comportamiento.

El problema se debía a que la estructura de directorios correspondiente al paquete de modelos tenía subpaquetes y todos los __init__.pyarchivos estaban vacíos. Deben importar explícitamente todas las clases requeridas en cada subcarpeta y en los modelos __init__.py para que Django las recoja con la makemigrationsherramienta.

models
  ├── __init__.py          <--- empty
  ├── patient
  │   ├── __init__.py      <--- empty
  │   ├── breed.py
  │   └── ...
  ├── timeline
  │   ├── __init__.py      <-- empty
  │   ├── event.py
  │   └── ...

Intente registrar su modelo en admin.py, aquí hay un ejemplo: - admin.site.register (YourModelHere)

Puede hacer lo siguiente: - 1. admin.site.register (YourModelHere) # En admin.py 2. Vuelva a cargar la página e intente nuevamente 3. Presione CTRL-S y guarde 4. Puede haber un error, especialmente verifique los modelos .py y admin.py 5. O, al final, reinicie el servidor

Con suerte, esto podría ayudar a alguien más, ya que terminé pasando horas tratando de perseguir esto.

Si tiene una función dentro de su modelo con el mismo nombre, esto eliminará el valor. Muy obvio en retrospectiva, pero no obstante.

Entonces, si tienes algo como esto:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

En ese caso, la función anulará la configuración anterior, haciéndola "invisible" makemigrations.

Lo mejor que puede hacer es eliminar la base de datos existente. En mi caso, estaba usando la base de datos SQL phpMyAdmin, por lo que eliminé manualmente la base de datos creada allí.

Después de eliminar: creo una base de datos en PhpMyAdmin y no agrego ninguna tabla.

Nuevamente ejecute los siguientes comandos:

python manage.py makemigrations

python manage.py migrate

Después de estos comandos : puede ver que django ha creado automáticamente otras tablas necesarias en la base de datos (aproximadamente hay 10 tablas).

python manage.py makemigrations <app_name>

python manage.py migrate

Y por último: después de los comandos anteriores, todos los modelos (tablas) que ha creado se importan directamente a la base de datos.

Espero que esto ayude.

Mi problema con este error fue que había incluido:

class Meta:
   abstract = True

Modelo interior para el que quería migrar la creación.

Tuve un problema diferente al crear una nueva aplicación llamada deals. Quería separar los modelos dentro de esa aplicación, así que tenía 2 archivos de modelo con nombre deals.pyy dealers.py. Cuando se ejecuta python manage.py makemigrationsllegué: No changes detected.

Seguí adelante y dentro del __init__.pyque vive en el mismo directorio donde vivían mis archivos de modelo (ofertas y distribuidor) que hice

from .deals import *
from .dealers import *

Y luego el makemigrationscomando funcionó.

Resulta que si no está importando los modelos a ninguna parte O el nombre de archivo de su modelo no está, models.pyentonces los modelos no serán detectados.

Otro problema que me sucedió es la forma en que escribí la aplicación en settings.py:

Yo tenía:

apps.deals

Debería haber incluido la carpeta del proyecto raíz:

cars.apps.deals