Django 1.7-makemigrations无法检测到更改

如标题所述，我似乎无法使迁移正常进行。

该应用程序最初的版本低于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。

如果要从django 1.6中制作的现有应用程序进行转换，则需要执行文档中列出的一个第一步（如我所知）：

python manage.py makemigrations your_app_label

该文档没有明显表明您需要在命令中添加应用标签，因为它首先告诉您要做的是python manage.py makemigrations失败。最初的迁移是在1.7版中创建的应用程序完成的，但是如果您来自1.6版，则不会进行。有关更多详细信息，请参见文档中的“向应用程序添加迁移”。

可能由于以下原因而发生：

1. 您没有在以下位置的INSTALLED_APPS列表中添加应用程序settings.py （您必须在应用程序文件夹的apps.py中添加应用程序名称或虚线路径到AppConfig的子类，具体取决于所使用的Django版本）。请参阅文档：INSTALLED_APPS
2. migrations这些应用程序内没有文件夹。（解决方案：只需创建该文件夹）。
3. 您没有这些应用程序__init__.py文件migrations夹中的文件。（解决方案：只需创建一个名称为__init__.py的空文件）
4. 您__init__.py的应用文件夹中没有文件。（解决方案：只需创建一个名称为__init__.py的空文件）
5. 您models.py的应用程序中没有文件
6. 您的Python类（假定是模型）models.py不会继承django.db.models.Model
7. 您在定义模型时存在语义错误 models.py

注意： 一个常见的错误是migrations在.gitignore文件中添加文件夹。从远程存储库克隆后，本地存储库中的文件migrations夹和/或__init__.py文件将丢失。这导致问题。

我建议通过在文件中添加以下几行来忽略迁移.gitignore文件

*/migrations/*
!*/migrations/__init__.py

好的，看来我错过了一个明显的步骤，但是在其他人也这样做的情况下发布了此步骤。

当升级到1.7时，我的模型变成了不受管理的（managed = False）-我像True以前一样拥有它们，但似乎已还原。

删除该行（默认情况下为True）然后makemigrations立即运行就构成了一个迁移模块，现在它可以正常工作了。makemigrations将不适用于非托管表（事后看来很明显）

我的解决方案未在此处介绍，因此我将其发布。我一直在使用syncdb一个项目-只是为了使其启动并运行。然后，当我尝试开始使用Django迁移时，它首先伪造了它们，然后说是“ OK”，但数据库没有任何反应。

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

然后，我进行了以下初步迁移：

./manage.py makemigrations my_app

其次是：

./manage.py migrate my_app

现在，我可以毫无问题地进行迁移了。

同意@furins。如果一切似乎都井然有序，但是仍然出现此问题，请检查是否有任何名称与要在Model类中添加的属性相同的属性方法。

1. 删除名称与要添加的属性类似的方法。
2. manage.py makemigrations my_app
3. manage.py迁移my_app
4. 重新添加方法。

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

复制粘贴def时会发生这种情况。从迁移本身定义为数组。

虽然这可能会帮助某人:-)

也许我来不及了，但是您是否尝试migrations在应用中创建一个__init__.py文件夹，其中包含文件？

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

答案是在此stackoverflow帖子上，由cdvv7788 在Django 1.7中进行迁移

如果是第一次迁移该应用程序，则必须使用：

manage.py makemigrations myappname完成后，您可以执行以下操作：

manage.py migration如果您的应用程序已包含在数据库中，请修改其模型并且不更新makemigrations上的更改，则您可能尚未迁移它。将您的模型改回其原始形式，运行第一个命令（使用应用程序名称）并迁移...它将对其进行伪造。完成后，将更改放回模型中，请运行makemigrations并再次进行迁移，它应该可以正常工作。

我遇到了完全相同的麻烦，并且执行上述操作完全正常。

我已将django应用程序移至cloud9，由于某种原因，我从未进行过初始迁移。

以下为我工作：

1. 将应用名称添加到settings.py
2. 使用'python manage.py makemigrations'
3. 使用'python manage.py migration'

为我工作：Python 3.4，Django 1.10

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

1. 删除您要同步的更改。
2. 运行python manage.py makemigrations app_label初始迁移。
3. python manage.py migrate进行更改之前，运行以创建表。
4. 粘贴您在第一步中删除的更改。
5. 运行步骤2.和3.。

如果您对这些步骤感到困惑，请阅读迁移文件。更改它们以更正您的架构或删除不需要的文件，但不要忘记更改下一个迁移文件的依赖项;）

我希望这会在将来对某人有所帮助。

你要检查settings.py的INSTALLED_APPS列表，并确保所有与模型的应用程序在那里上市。

makemigrations在项目文件夹中运行意味着它将寻找更新与settings.py项目中包含的所有应用程序相关的所有表。包含它后，makemigrations将自动包含该应用程序（这样可以节省大量工作，因此您不必makemigrations app_name为项目/站点中的每个应用程序都运行）。

以防万一您有一个不能由makemigrations标识的特定字段：检查两次是否具有相同名称的属性。

例：

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

# ... later

@property
def field(self):
    pass

该属性将“覆盖”字段定义，因此更改不会被 makemigrations

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

添加此答案是因为只有此方法对我有帮助。

我删除了migrations文件夹run makemigrations和migrate。
它仍然说：没有迁移申请。

我转到migrate文件夹并打开了最后一个创建的文件，
注释了我想要的迁移（已检测到并在此输入）
并migrate再次运行。

这基本上是手动编辑迁移文件。
仅当您了解文件内容时，才执行此操作。

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

遇到相同的问题确保您在models.py中定义了任何类，您必须必须继承models.Model类。

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

我不得不两次运行makemigrations和各种奇怪的行为时遇到了同样的问题。事实证明，问题的根源在于我正在使用一个函数来设置模型中的默认日期，因此每次我进行makemigrations时，迁移都会检测到更改。这个问题的答案使我走上了正确的轨道：避免进行重新创建日期字段的迁移

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

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

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

我只是想在这里分享它，如果有人遇到相同的问题（schemamigrations他们的应用程序有问题），可能会对他们有所帮助:)

也许可以帮助某人，但我遇到了同样的问题。

我已经用序列化程序类和视图创建了两个表。因此，当我想更新时，出现了此错误。

我按照以下步骤操作：

1. 我做了 .\manage.py makemigrations app
2. 我执行了 .\manage.py migrate
3. 我删除了我的两个表 models.py
4. 我从序列化程序和视图类中删除了对表的所有引用。
5. 我执行了step 1和2。
6. 我只是在 models.py
7. 我再次执行步骤5。
8. 我恢复了所有更改。

如果您正在使用Pycharm，则本地历史记录将非常有帮助。

也许这会帮助某人。

我已经删除了，models.py并希望makemigrations创建DeleteModel语句。

记住要删除*.pyc文件！

./manage makemigrations
./manage migrate

迁移会跟踪对数据库的更改，因此，如果您从非托管更改为托管，则需要确保您的数据库表与您要处理的模型有关的最新信息。

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

记住：如果您的迁移在IDE中以_001结尾，在数据库中以_003结尾。Django仅会查看您是否有以_004结尾的迁移来更新任何内容。

2（代码和数据库迁移）是链接在一起的，并且可以协同工作。

快乐的编码。

1. 删除您要同步的更改。
2. 运行python manage.py makemigrations app_label进行初始迁移。
3. 进行更改之前，请运行python manage.py migration来创建表。
4. 粘贴您在第一步中删除的更改。
5. 运行步骤2和3。

添加了此答案，因为上面没有其他可用的方法适合我。

在我的情况下，发生了更奇怪的事情（Django 1.7版本），在我的models.py文件的末尾有一个“额外”行（这是一个空行），当我执行python manage.py makemigrations命令时，结果是：“未检测到更改”。

要解决此问题，我删除了我的models.py文件末尾的“空白行”，并再次运行了该命令，所有问题均已修复，并且检测到对models.py所做的所有更改！

您可能需要使用以下命令来伪造初始迁移

python manage.py migrate --fake-initial

首先，此解决方案适用于在heroku服务器上部署期间遇到相同问题的用户，而我也面临相同的问题。

要进行部署，有一个强制性步骤是在settings.py文件中添加django_heroku.settings（locals（））。

更改：当我将上述行更改为django_heroku.settings（locals（），database = False）时，它可以正常工作。

就我而言，我需要将模型添加到定义了模型的models文件夹的_ init _.py文件中：

from myapp.models.mymodel import MyModel

添加我的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...线路可解决问题！

python manage.py makemigrations帐户“帐户”的迁移：accounts \ migrations \ 0001_initial.py-创建模型客户-创建模型标签-创建模型产品-创建模型订单

注意：这里的“帐户”是我的应用名称