首页 文章

Django 1.7 - makemigrations没有检测到变化

提问于
浏览 次
122

正如 Headers 所说，我似乎无法让迁移工作 .

该应用程序最初低于1.6，因此我了解迁移最初不会存在，事实上如果我运行 python manage.py migrate 我得到：

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.

如果我对 myapp 中的任何模型进行了更改，它仍然会按预期显示未迁移 .

但如果我跑 python manage.py makemigrations myapp 我得到：

No changes detected in app 'myapp'

似乎没关系我运行命令的内容或方式，它从未检测到应用程序有更改，也没有将任何迁移文件添加到应用程序 .

有没有办法迫使应用程序进行迁移，并基本上说“这是我的工作基础”或任何东西？或者我错过了什么？

我的数据库是一个PostgreSQL，如果它有帮助的话 .

python django django-1.7 django-migrations

23 回答

  • 1

    也许这会对某人有所帮助 .

    我删除了我的 models.py 并期望 makemigrations 来创建 DeleteModel 语句 .

    记得删除 *.pyc 文件！

    回复于
  • 11

    同意@furins . 如果一切看起来都是有序的，但是出现了这个问题，请检查是否有任何属性方法与您尝试在Model类中添加的属性具有相同的 Headers .

    • 删除与要添加的属性具有相似名称的方法 .

    • manage.py makemigrations my_app

    • manage.py迁移my_app

    • 重新添加方法 .

    回复于
  • 7

    如果您要从django 1.6中的现有应用程序进行切换，那么您需要执行文档中列出的一个前置步骤（如我所知）：

    python manage.py makemigrations your_app_label

    文档并没有明确表示您需要将app标签添加到命令中，因为它告诉您要做的第一件事是 python manage.py makemigrations 将失败 . 初始迁移是在1.7版本中创建应用程序时完成的，但如果您来自1.6，则不会执行 . 有关详细信息，请参阅文档中的'Adding migration to apps' .

    回复于
  • 6

    好吧，看起来我错过了一个明显的步骤，但发布这个以防其他人也这样做 .

    当升级到1.7时，我的模型变得不受管理（ managed = False ） - 之前我把它们作为 True 但似乎已经恢复了 .

    删除该行（默认为True）然后运行 makemigrations 立即创建了一个迁移模块，现在它正在运行 . makemigrations 不适用于非托管表（事后证明这一点很明显）

    回复于
  • 1

    我的解决方案没有在这里讨论，所以我发布了它 . 我一直在使用 syncdb 进行项目 - 只是为了让它运行起来 . 然后，当我尝试开始使用Django迁移时，它首先伪造它们然后会说它是'OK'但数据库没有发生任何事情 .

    我的解决方案是删除我的应用程序的所有迁移文件，以及 django_migrations 表中应用程序迁移的数据库记录 .

    然后我刚做了一个初始迁移：

    ./manage.py makemigrations my_app

    其次是：

    ./manage.py migrate my_app

    现在我可以毫无问题地进行迁移 .

    回复于
  • 6

    这可能是由于以下原因：

    • 您未在 settings.py 中的 INSTALLED_APPS 列表中添加应用程序（您必须在应用程序文件夹的apps.py中添加 app name 或点缀路径到AppConfig的子类，具体取决于您使用的django版本） . 请参阅文档：INSTALLED_APPS

    • 您在这些应用程序中没有 migrations 文件夹 . （解决方案：只创建该文件夹） .

    • 这些应用程序的 migrations 文件夹中没有 init.py 文件 . （解决方案：只需创建一个名为 init.py 的空文件）

    • 您在app文件夹中没有 init.py 文件 . （解决方案：只需创建一个名为 init.py 的空文件）

    • 您的应用中没有 models.py 文件

    • models.py 中的Python类（应该是模型）不继承 django.db.models.Model

    • models.py 中模型定义中存在语义错误

    Note: 常见的错误是在 .gitignore 文件中添加 migrations 文件夹 . 从远程仓库克隆时，本地仓库中将丢失 migrations 文件夹和/或 __init__.py 文件 . 这会导致问题 .

    我建议通过将以下行添加到 .gitignore 文件来忽略迁移文件

    */migrations/*
!*/migrations/__init__.py
    回复于
  • 6

    这是一个愚蠢的错误，但在模型类的字段声明行的末尾有一个额外的逗号，使该行无效 .

    当您复制粘贴def时会发生这种情况 . 来自迁移，它本身被定义为一个数组 .

    虽然这可能有助于某人:-)

    回复于
  • -1

    答案是在这个stackoverflow帖子上，由cdvv7788 Migrations in Django 1.7

    如果您是第一次迁移该应用程序，则必须使用：manage.py makemigrations myappname执行此操作后，您可以执行以下操作：manage.py migrate如果您的应用程序位于数据库中，修改了它的模型并且没有更新makemigrations上的更改，你可能还没有迁移它 . 将模型更改回原始形式，运行第一个命令（使用应用程序名称）并迁移...它会伪造它 . 一旦这样做，就可以在模型上放回更改，运行makemigrations并再次迁移，它应该可以正常工作 .

    我遇到了同样的麻烦，并且完成了上述工作 .

    我已经将我的django应用程序移动到了cloud9，由于某种原因，我从未捕获过初始迁移 .

    回复于
  • 1

    也许这会对某人有所帮助 . 我正在使用嵌套的应用程序 . project.appname和我实际上在INSTALLED_APPS中有project和project.appname . 从INSTALLED_APPS中删除项目允许检测更改 .

    回复于
  • 3

    像我这样不喜欢迁移的人可以使用以下步骤 .

    • 删除要更改的内容 .

    • 运行 python manage.py makemigrations app_label 进行初始迁移 .

    • 运行 python manage.py migrate 以在进行更改之前创建表 .

    • 粘贴您在第一步中删除的更改 .

    • 运行2.和3.步骤 .

    如果您混淆了这些步骤，请阅读迁移文件 . 更改它们以更正您的架构或删除不需要的文件，但不要忘记更改下一个迁移文件的依赖项部分;）

    我希望这将有助于将来的某些人 .

    回复于
  • 5

    以下为我工作：

    • 将应用名称添加到settings.py

    • 使用'python manage.py makemigrations'

    • 使用'python manage.py migrate'

    为我工作：Python 3.4，Django 1.10

    回复于
  • 15

    也许我来不及但是你试着在你的应用程序中有一个 migrations 文件夹中有一个 __init__.py 文件吗？

    回复于
  • 17

    您想检查 INSTALLED_APPS 列表中的 settings.py 并确保其中列出了所有带模型的应用程序 .

    在项目文件夹中运行 makemigrations 意味着它将查找更新与项目的 settings.py 中包含的所有应用程序相关的所有表 . 一旦你包含它， makemigrations 将自动包含应用程序（这节省了大量的工作，因此你不必为你的项目/网站中的每个应用程序运行 makemigrations app_name ） .

    回复于
  • 6

    以防万一你有一个特定的字段没有被makemigrations识别：如果你有一个具有相同名称的属性，请检查两次 .

    例：

    field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

    该属性将"overwrite"字段定义，因此 makemigrations 无法识别更改

    回复于
  • 4

    添加此答案，因为只有这种方法帮助了我 .

    我删除了 migrations 文件夹，运行 makemigrations 和 migrate .
    它仍然说：没有适用的迁移 .

    我去了 migrate 文件夹并打开了最后创建的文件，
    评论我想要的迁移（它被检测到并进入那里）
    并再次运行 migrate .

    这基本上是手动编辑迁移文件 .
    Do this only if you understand the file content.

    回复于
  • 1

    确保您的模型不是 abstract . 我实际上犯了这个错误，花了一段时间，所以我想我会发布它 .

    回复于
  • 1

    重命名旧的迁移文件夹后，您使用了 schemamigration my_app --initial 吗？试试吧 . 可能会工作 . 如果不是 - 尝试重新创建数据库并使syncdb迁移 . 它对我有用......

    回复于
  • 25

    我有两次运行makemigrations和各种奇怪行为的问题 . 原来问题的根源在于我使用了一个函数在我的模型中设置默认日期，因此每次运行makemigrations时迁移都会检测到更改 . 这个问题的答案让我走上正轨：Avoid makemigrations to re-create date field

    回复于
  • 4

    我最近将Django从1.6升级到1.8，并且几乎没有应用程序和迁移 . 我使用south和 schemamigrations 在Django 1.6中创建了迁移，在Django 1.8中删除了它 .

    升级后添加新模型时， makemigrations 命令未检测到任何更改 . 然后我尝试了@drojf建议的解决方案（第一个答案），它工作正常，但未能应用虚假的初始迁移（ python manage.py --fake-initial ） . 我这样做是因为我的表（旧表）已经创建了 .

    最后这对我有用，从models.py中删除了新模型（或模型更改），然后必须删除（或重命名安全备份）所有应用程序的迁移文件夹，并为所有应用程序运行python manage.py makemigrations，然后执行 python manage.py migrate --fake-initial . 这就像一个魅力 . 为所有应用创建初始迁移并假冒初始迁移后，添加新模型并遵循常规流程 makemigrations 并在该应用上迁移 . 现在检测到这些变化，一切都很顺利 .

    我只是想在这里分享它，如果有人面临同样的问题（他们的应用程序有南方 schemamigrations ），它可能会帮助他们:)

    回复于
  • 18

    也许这可以帮助有人，我有同样的问题 .

    我已经用序列化器类和视图创建了两个表 . 所以，当我想要更新时，我遇到了这个错误 .

    我按照这个步骤：

    • 我做了 .\manage.py makemigrations app

    • 我执行了 .\manage.py migrate

    • 我删除了我的 models.py 两个表

    • 我从序列化程序和视图类中删除了对表的所有引用 .

    • 我执行了步骤 1 和 2 .

    • 我在 models.py 中检索了我的更改

    • 我再次执行了步骤 5 .

    • 我恢复了所有更改 .

    如果您正在使用Pycharm，那么本地历史非常有用 .

    回复于
  • 4
    ./manage makemigrations
./manage migrate

    迁移跟踪对DB的更改，因此如果您从非托管更改为托管，则需要确保您的数据库表是与您正在处理的模型相关的最新版本 .

    如果您仍处于开发模式，我个人决定删除IDE中的迁移文件以及与我的模型相关的django_migrations表，并重新运行上述命令 .

    请记住：如果您的IDE中的_001和数据库中的_003的迁移结束 . Django只会看到你是否有一个以_004结尾的迁移来更新任何内容 .

    2（代码和数据库迁移）链接并协同工作 .

    快乐的编码 .

    回复于
  • 169

    添加了这个答案，因为以上其他任何一个都不适合我 .

    在我的情况下发生了一些更奇怪的事情（ Django 1.7 Version ），在我的 models.py 中，我的文件末尾有一条 "extra" 行（它是一个空白行），当我执行 python manage.py makemigrations 命令时，结果是： "no changes detected".

    为了解决这个问题，我删除了 models.py ，这是在我的 models.py 文件的末尾，我确实再次运行了命令，一切都已修复，所有对_1714443的更改都被检测到了！

    回复于
  • 0

    添加我的2c，因为这些解决方案都不适用于我，但这确实......

    我刚刚运行了 manage.py squashmigrations 并删除了旧的迁移（django.migrations数据库表中的文件和行） .

    这在上一个迁移文件中留下了这样的一行：

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

    这显然混淆了Django并导致了奇怪的行为：运行 manage.py makemigrations my_app 将重新创建初始迁移，就好像不存在一样 . 删除 replaces... 行修复了问题！

    回复于

相关问题