我试图使用makemigrations命令在现有的应用程序中创建迁移,但它输出“未检测到更改”。

通常我使用startapp命令创建新的应用程序,但在创建这个应用程序时没有使用它。

调试后,我发现它没有创建迁移,因为迁移包/文件夹从应用程序中丢失。

如果文件夹不存在或者我遗漏了什么,如果它创建文件夹会更好吗?


当前回答

当向django api应用程序添加新模型并运行python manage.py makemigrations时,工具没有检测到任何新模型。

奇怪的是,旧模型确实被makemigrations选中了,但这是因为它们在urlpatterns链中被引用,而工具以某种方式检测到了它们。所以要注意这种行为。

这个问题是因为与models包对应的目录结构有子包,并且所有__init__.py文件都是空的。它们必须显式地在每个子文件夹和__init__.py模型中导入所有必需的类,以便Django使用makemigrationations工具来获取它们。

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

其他回答

我读过很多关于这个问题的答案,通常都是简单地用其他方式进行移民。但对我来说,问题在于模型的Meta子类。

我有一个应用程序配置,说label = <应用程序名称>(在apps.py文件,旁边的models.py, views.py等)。如果你的元类没有与应用标签相同的标签(例如,因为你把一个太大的应用拆分成多个),就不会检测到任何变化(也不会有任何有用的错误消息)。所以在我的模型类中,我现在有:

class ModelClassName(models.Model):

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

    field_name = models.FloatField()
    ...

运行Django 1.10。

更新:在尝试之前,应该确保migrations文件夹中存在__init__.py文件:

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


有时。/manage.py makemigrations优于。/manage.py makemigrations <myapp>,因为它可以处理应用程序之间的某些冲突。

这些情况都是悄无声息地发生的,需要几个小时的咒骂才能理解可怕的“检测到没有变化”消息的真正含义。

因此,使用下面的命令是一个更好的选择:

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

确保你的应用在settings.py中的installed_apps中被提及 确保建模类扩展了模型。模型

我有一个属性与我试图用makemigrations添加的字段同名。

另一个会导致这种情况的是字段后面的尾随逗号,这将导致在makemigrationations期间跳过字段:

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

我有一个拖尾,在一行中,可能来自复制粘贴。带有is_dumb的代码行不会使用./manage.py makemigrations创建模型迁移,因为Python认为它是一个元组,而Django不认为它是一个字段。