Django - makemigrations - No se detectaron cambios

138

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?

Dilraj
fuente
13
¿Tiene su aplicación agregada a INSTALLED_APPS?
wolendranh
66
Sí, está en la aplicación instalada, por primera vez, es mejor usarlo makemigrations <myapp>como señaló Alasdair también.
Dilraj
1
Eliminar 'abstract = True' :)
GrvTyagi
'makemigrations' no funcionó. 'makemigrations <myapp>' funcionó
Aseem

Respuestas:

267

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).

Alasdair
fuente
15
¿Alguna idea de por qué a veces nos obligan a especificar la aplicación?
maazza
40
@maazza necesita especificar el nombre de la aplicación si la aplicación no tiene migrationscarpeta. Esto podría suceder si creó la aplicación manualmente o si ha actualizado desde una versión anterior de Django que no tenía migraciones.
Alasdair
13
@maazza En realidad, necesitas un paquete de Python (con __init__.py) llamado 'migraciones' en la aplicación.
Jibin
3
Suena como algo que Django debería manejar automáticamente.
dualidad_
1
@duality_ esto es por diseño : Django no asume que quieres migraciones para tu aplicación. Si creaba migraciones para todas las aplicaciones, podría generar errores cuando ejecuta migrate.
Alasdair
49

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

Karina Klinkevičiūtė
fuente
Esto resultó ser la solución para mí también, pero no entiendo por qué es así. ¿Alguien tiene alguna idea de lo que puede estar causando esto?
Paul in 't Hout
Django tiene una ruta predeterminada de dónde buscar sus modelos. Si la estructura del proyecto es diferente y los modelos no están en el lugar habitual, deben importarse allí.
Karina Klinkevičiūtė
@ KarinaKlinkevičiūtė ¿y si necesito eliminar esos modelos?
Daniil Mashkin
@DaniilMashkin Me imagino que también necesitarías eliminar las importaciones. Esta es una de las formas de estructurar su proyecto (no el único) y tiene que ocuparse de las tareas adicionales que
conlleva
1
Utilicé la arquitectura "clásica" para los modelos, luego migré a la arquitectura de la "carpeta de modelos", y todavía se detecta cualquier migración en mis modelos existentes. Sin embargo, ahora, al crear un nuevo modelo, tengo este problema. Su solución funciona bien, pero deja que mi base de código sea inconsistente porque a veces hay una importación, a veces no. Quizás haya una mejor solución. Supongo que Django debería proponer una configuración con una lista de carpetas para buscar al intentar encontrar nuevos modelos.
David D.
44

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,

usuario1134422
fuente
1
Cubierto muchos escenarios con respecto al problema, debe ser la respuesta aceptada.
Krishh
Otra posibilidad: se está importando un nombre incorrecto, es decir, importar un campo desde formularios en lugar de campos, o importar un modelo desde formularios en lugar de modelos. Un ejemplo: from recurrence.forms import RecurrenceFieldpero debería haber sido from recurrence.fields import RecurrenceField.
hlongmore
Una razón más Asegúrese de que el modelo se use dentro de una ruta para el sitio web (a través del administrador o de otro modo). "El makemigrationsscript busca modelos que están conectados desde urls.py". Encontrado aquí stackoverflow.com/questions/43093651/…
Kyle
Ejemplo de cmd:python manage.py makemigrations -v 3 <app_name>
Charlie 木匠
Cuando agrego una tabla, y luego agrego una referencia de clave externa a esta nueva tabla al mismo tiempo. Tiene que dividirse en 2 pasos: paso previo: agregue INSTALLED_APPS a la configuración. 1) crear una nueva tabla: python manage.py makemigrations <app_name>; 2) agregar clave externa: python manage.py makemigrations
Charlie 木匠
26

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í.

onekiloparsec
fuente
13

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
Stephen
fuente
pero crea el nombre de la tabla como 'appname_modelname', cuando ejecutamos el comando 'manage.py migrate'
Daniyal Javaid el
Vea las meta opciones del modelo para cambiar el nombre de la tabla
stephen
11

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 :-)

yvess
fuente
La coma final también puede causar errores en otros lugares; la coma convierte la declaración en una tupla, por lo que is_dumbes igual a la (models.BooleanField(default=False), )que makemigrationsno sabe cómo convertir en una columna de base de datos.
hlongmore
8

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>

raratiru
fuente
7

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.

Dan Cogswell
fuente
4
  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.
Amandeep Singh
fuente
2

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".
Juan David Argüello Plata
fuente
2

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'

CodeToLife
fuente
2

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.

Nick Lothian
fuente
2

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.

drchuck
fuente
1

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.

sradha
fuente
1

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

Piyush Chandra
fuente
1

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")]
nbeuchat
fuente
1

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!

Tim
fuente
1

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.

Yair Abad
fuente
0

Usted debe agregar polls.apps.PollsConfiga INSTALLED_APPSensetting.py

gatito
fuente
0

En mi caso olvidé insertar los argumentos de clase

Incorrecto:

class AccountInformation():

Correcto

class AccountInformation(models.Model):
Jonas
fuente
0

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.

Tolga
fuente
0

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.

Akash G Krishnan
fuente
0

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.

kgeo
fuente
0

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.

Irshu
fuente
0

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
     └── ...
atoledo
fuente
0

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

GURU RAJ
fuente
0

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.

vpetersson
fuente
0

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.

HUPESH GUPTA
fuente
0

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.

Dolidod Teethtard
fuente
0

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
elad plata
fuente