Python Django 1.7 - makemigrations 未检测到更改

Django 1.7 - makemigrations not detecting changes

提问by TyrantWave

As the title says, I can't seem to get migrations working.

正如标题所说，我似乎无法让迁移工作。

The app was originally under 1.6, so I understand that migrations won't be there initially, and indeed if I run python manage.py migrateI get:

该应用程序最初低于 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.

If I make a change to any models in myapp, it still says unmigrated, as expected.

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

But if I run python manage.py makemigrations myappI get:

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

No changes detected in app 'myapp'

Doesn't seem to matter what or how I run the command, it's never detecting the app as having changes, nor is it adding any migration files to the app.

我运行命令的内容或方式似乎无关紧要，它永远不会检测到应用程序有更改，也不会向应用程序添加任何迁移文件。

Is there any way to force an app onto migrations and essentially say "This is my base to work with" or anything? Or am I missing something?

有什么方法可以强制应用程序迁移并基本上说“这是我的工作基础”或其他任何内容？或者我错过了什么？

My database is a PostgreSQL one if that helps at all.

如果有帮助的话，我的数据库是 PostgreSQL 数据库。

采纳答案by TyrantWave

Ok, looks like I missed an obvious step, but posting this in case anyone else does the same.

好的，看起来我错过了一个明显的步骤，但张贴这个以防其他人做同样的事情。

When upgrading to 1.7, my models became unmanaged (managed = False) - I had them as Truebefore but seems it got reverted.

升级到 1.7 时，我的模型变得不受管理 ( managed = False) - 我像True以前一样拥有它们，但似乎已恢复。

Removing that line (To default to True) and then running makemigrationsimmediately made a migration module and now it's working. makemigrationswill not work on unmanaged tables (Which is obvious in hindsight)

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

回答by Alex Vidis

Did u use schemamigration my_app --initialafter renaming old migration folder? Try it. Might work. If not - try to recreate the database and make syncdb+migrate. It worked for me...

您schemamigration my_app --initial在重命名旧迁移文件夹后使用了吗？尝试一下。可能工作。如果没有 - 尝试重新创建数据库并进行同步数据库+迁移。它对我有用...

回答by drojf

If you're changing over from an existing app you made in django 1.6, then you need to do one pre-step (as I found out) listed in the documentation:

如果您要从在 django 1.6 中制作的现有应用程序转换过来，那么您需要执行文档中列出的一个预先步骤（正如我发现的那样）：

python manage.py makemigrations your_app_label

python manage.py makemigrations your_app_label

The documentation does not make it obvious that you need to add the app label to the command, as the first thing it tells you to do is python manage.py makemigrationswhich will fail. The initial migration is done when you create your app in version 1.7, but if you came from 1.6 it wouldn't have been carried out. See the 'Adding migration to apps'in the documentation for more details.

该文档没有明确说明您需要将应用程序标签添加到命令中，因为它告诉您要做的第一件事就是python manage.py makemigrations失败。当您在 1.7 版中创建应用程序时，初始迁移已完成，但如果您来自 1.6 版，则不会执行。有关更多详细信息，请参阅文档中的“向应用程序添加迁移”。

回答by PhoebeB

I had the same problem with having to run makemigrations twice and all sorts of strange behaviour. It turned out the root of the problem was that I was using a function to set default dates in my models so migrations was detecting a change every time I ran makemigrations. The answer to this question put me on the right track: Avoid makemigrations to re-create date field

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

回答by Grant Eagon

My solution was not covered here so I'm posting it. I had been using syncdbfor a project–just to get it up and running. Then when I tried to start using Django migrations, it faked them at first then would say it was 'OK' but nothing was happening to the database.

我的解决方案没有在这里涵盖，所以我发布了它。我一直在syncdb用于一个项目——只是为了让它启动和运行。然后，当我尝试开始使用 Django 迁移时，它首先伪造了它们，然后会说它“正常”，但数据库没有发生任何事情。

My solution was to just delete all the migration files for my app, as wellas the database records for the app migrations in the django_migrationstable.

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

Then I just did an initial migration with:

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

./manage.py makemigrations my_app

./manage.py makemigrations my_app

followed by:

其次是：

./manage.py migrate my_app

./manage.py migrate my_app

Now I can make migrations without a problem.

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

回答by jaywhy13

Maybe this will help someone. I was using a nested app. project.appname and I actually had project and project.appname in INSTALLED_APPS. Removing project from INSTALLED_APPS allowed the changes to be detected.

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

回答by Sticky

You want to check the settings.pyin the INSTALLED_APPSlist and make sure all the apps with models are listed in there.

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

Running makemigrationsin the project folder means it will look to update all the tables related to all the apps included in settings.pyfor the project. Once you include it, makemigrationswill automatically include the app (this saves a lot of work so you don't have to run makemigrations app_namefor every app in your project/site).

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

回答by MicahT

The answer is on this stackoverflow post, by cdvv7788 Migrations in Django 1.7

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

If it is the first time you are migrating that app you have to use:

manage.py makemigrations myappname Once you do that you can do:

manage.py migrate If you had your app in database, modified its model and its not updating the changes on makemigrations you probably havent migrated it yet. Change your model back to its original form, run the first command (with the app name) and migrate...it will fake it. Once you do that put back the changes on your model, run makemigrations and migrate again and it should work.

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

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

manage.py migrate 如果您的应用程序在数据库中，修改了它的模型并且它没有更新 makemigrations 上的更改，那么您可能还没有迁移它。将您的模型改回其原始形式，运行第一个命令（使用应用程序名称）并迁移......它会伪造它。这样做后，将更改放回模型，运行 makemigrations 并再次迁移，它应该可以工作。

I was having the exact same trouble and doing the above worked perfectly.

我遇到了完全相同的问题，并且上述操作完美无缺。

I had moved my django app to cloud9 and for some reason I never caught the initial migration.

我已将我的 django 应用程序移至 cloud9，但出于某种原因，我从未遇到过最初的迁移。

回答by furins

Just in case you have a specific field that does not get identified by makemigrations: check twice if you have a property with the same name.

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

example:

例子：

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

# ... later

@property
def field(self):
    pass

the property will "overwrite" the field definition so changes will not get identified by makemigrations

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

回答by Iman Akbari

This is kind of a stupid mistake to make, but having an extra comma at the end of the field declaration line in the model class, makes the line have no effect.

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

It happens when you copy paste the def. from the migration, which itself is defined as an array.

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

Though maybe this would help someone :-)

虽然也许这会帮助某人:-)