new - migrate model django

Django-makemigrations-No se detectaron cambios

Question

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 comando startapp pero no lo startapp para esta aplicación cuando la creé.

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

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

Answer 1

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.

Answer 2

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

Esas ocasiones ocurren en silencio y toma varias horas de swearing para entender el verdadero significado del temido mensaje No changes detected .

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

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

Answer 3

Debe agregar polls.apps.PollsConfig a INSTALLED_APPS en setting.py

Answer 4

En primer lugar, asegúrese de que su aplicación esté registrada en Installed_app en la configuración.py Luego, la respuesta anterior funciona perfectamente bien

Answer 5

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

Asegúrese de que el nombre de su aplicación esté en settings.py INSTALLED_APPS contrario, no importa lo que haga, no ejecutará 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

Answer 6

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.

Answer 7

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

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 INSTALLED_APPS .dict
3. Verbosity comienza ejecutando makemigrations -v 3 para verbosity. Esto podría arrojar algo de luz sobre el problema.
4. Ruta completa En INSTALLED_APPS se recomienda especificar la ruta de configuración de la aplicación del módulo completo ''apply.apps.MyAppConfig''
5. - configuración, es posible que desee asegurarse de que se haya configurado el archivo de configuración correcto: manage.py makemigrations --settings mysite.settings
6. especifique el nombre de la aplicación explícitamente, póngalo en manage.py makemigrations myapp , que reduce las migraciones solo para la aplicación y lo ayuda a aislar el problema.

7. app_label modelo tiene la app_label correcta en 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 método allow_syncdb .

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

Answer 8

He leído muchas respuestas a esta pregunta, a menudo afirmando simplemente ejecutar makemigrations de alguna otra manera. Pero para mí, el problema estaba en la subclase Meta de modelos.

Tengo una configuración de aplicación que dice label = <app name> (en el archivo apps.py , junto a models.py , views.py , etc.). 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 en absoluto). 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í.

Answer 9

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 de makemigrations python3 manage.py o el nombre de su aplicación

Answer 10

La solución es que debes incluir tu aplicación en INSTALLED_APPS.

Lo perdí y encontré este mismo problema.

después de especificar 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.

Answer 11

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

No estaba usando el archivo models.py , pero creé un directorio de models y creé el archivo my_model.py 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__.py agregué esta línea: from .my_model import MyModel

Answer 12

Olvidé poner los 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''

Answer 13

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

./manage.py makemigrations <myapp>

Su aplicación debe estar incluida en INSTALLED_APPS primero (dentro de settings.py).

Answer 14

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

Answer 15

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 estaban importando en otro lugar que terminó importando desde main_app que estaba registrado en INSTALLED_APPS , tuve la suerte de que todos funcionaran.

Pero como solo agregué cada app a INSTALLED_APPS y no a app_sub* cuando finalmente agregué un nuevo archivo de modelos que no se importó EN app_sub* LUGAR, Django lo ignoró por completo.

Mi solución fue agregar un archivo models.py al directorio base de cada app esta manera ...

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 nivel de app 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!

Answer 16

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

Answer 17

Un problema muy tonto que puede tener también es definir class Meta dos class Meta en su modelo. En ese caso, cualquier cambio en el primero no se aplicará al ejecutar 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")]