Python Django 1.7 - 在 makemigrations 后运行 migrate 时“没有应用迁移”

Django 1.7 - "No migrations to apply" when run migrate after makemigrations

提问by matousc

I use Django1.7 with Mezzanine. I create simple profile (according to Mezzanine documentation) stored in separate app "profiles":

我将 Django1.7 与 Mezzanine 一起使用。我创建了存储在单独的应用程序“配置文件”中的简单配置文件（根据夹层文档）：

class RoadmapProfile(models.Model):
    user = models.OneToOneField("auth.User")
    fullname = models.CharField(max_length=100, verbose_name="Full name")

Creation of migrations returns:

创建迁移返回：

  Migrations for 'profiles':
      0001_initial.py:
        - Create model RoadmapProfile

When I run "migrate profiles":

当我运行“迁移配置文件”时：

Operations to perform:
  Apply all migrations: profiles
Running migrations:
  No migrations to apply.

The issue is, when I try to open any page related to mezzanine.accounts (for example update account), it crashes with:

问题是，当我尝试打开与 mezzanine.accounts 相关的任何页面（例如更新帐户）时，它会崩溃：

OperationalError at /accounts/update/

no such column: profiles_roadmapprofile.fullname

What I have done wrong?

我做错了什么？

采纳答案by ACimander

Sounds like your initial migration was faked because the table already existed (probably with an outdated schema):

听起来您的初始迁移是伪造的，因为该表已经存在（可能具有过时的架构）：

https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps

https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps

"This will make a new initial migration for your app. Now, when you run migrate, Django will detect that you have an initial migration and that the tables it wants to create already exist, and will mark the migration as already applied."

“这将为您的应用程序创建一个新的初始迁移。现在，当您运行 migrate 时，Django 将检测到您有一个初始迁移并且它想要创建的表已经存在，并将迁移标记为已经应用。”

Otherwise you would get an no-such-table error :)

否则你会得到一个 no-such-table 错误 :)

[edit] did you clean up the applied-migrations table? That's also a common cause for non-applied migrations.

[编辑] 您是否清理了应用迁移表？这也是非应用迁移的常见原因。

回答by Zulfugar Ismayilzadeh

1. In MySQL Database delete row 'profiles'from the table 'django_migrations'.
2. Delete all migration files in migrations folder.
3. Try again python manage.py makemigrationsand python manage.py migratecommand.

1. 在 MySQL 数据库中'profiles'从表中删除行'django_migrations'。
2. 删除迁移文件夹中的所有迁移文件。
3. 再试一次python manage.py makemigrations并python manage.py migrate命令。

回答by masood

1- run python manage.py makemigrations <appname>

1-运行蟒蛇 manage.py makemigrations <appname>

2- run python manage.py sqlmigrate <appname> <migrationname>- you will find migrationname in migration folder under appname (without '.py' extension of course)

2-运行python-manage.py sqlmigrate <appname> <migrationname>您将在appname下的迁移文件夹中找到migrationname（当然没有'.py'扩展名）

3- copy all text of result # all sql commands that generated
4- go to your db ide and paste as new query and run it

3- 复制结果的所有文本 # 生成的所有 sql 命令
4- 转到您的 db ide 并粘贴为新查询并运行它

now all changes are applied on your db

现在所有更改都应用于您的数据库

回答by phanhuy152

I am a Django newbie and I was going through the same problem. These answers didn't work for me. I wanted to share how did I fix the problem, probably it would save someone lots of time.

我是 Django 新手，我遇到了同样的问题。这些答案对我不起作用。我想分享我是如何解决这个问题的，可能会节省很多时间。

Situation:

情况：

I make changes to a model and I want to apply these changes to the DB.

我对模型进行了更改，并且想将这些更改应用于数据库。

What I did:

我做了什么：

Run on shell:

在外壳上运行：

python manage.py makemigrations app-name
python manage.py migrate app-name

What happened:

发生了什么：

• No changes are made in the DB

• But when I check the db schema, it remains to be the old one

• 数据库中未进行任何更改

• 但是当我检查数据库模式时，它仍然是旧的

Reason:

原因：

• When I run python manage.py migrate app-name, Django checks in django_migrations table in the db to see which migrations have been already applied and will skip those migrations.

• 当我运行 python 时manage.py migrate app-name，Django 检查数据库中的 django_migrations 表以查看已经应用了哪些迁移并将跳过这些迁移。

What I tried:

我试过的：

Delete the record with app="my-app-name" from that table (delete from django_migrations where app = "app-name"). Clear my migration folder and run python manage.py makemigration my-app-name, then python manage.py migrate my-app-name. This was suggested by the most voted answer. But that doesn't work either.

从该表 ( delete from django_migrations where app = "app-name") 中删除 app="my-app-name" 的记录。清除我的迁移文件夹并运行python manage.py makemigration my-app-name，然后python manage.py migrate my-app-name. 这是投票最多的答案所建议的。但这也行不通。

Why?

为什么？

Because there was an existing table, and what I am creating was a "initial migration", so Django decides that the initial migration has already been applied (Because it sees that the table already exists). The problem is that the existing table has a different schema.

因为有一个现有的表，而我正在创建的是一个“初始迁移”，所以 Django 决定已经应用了初始迁移（因为它看到该表已经存在）。问题在于现有表具有不同的架构。

Solution 1:

解决方案1：

Drop the existing table (with the old schema), make initial migrations, and applied again. This will work (it worked for me) since we have an "initial migration" and there was no table with the same name in our db. (Tip: I used python manage.py migrate my-app-name zeroto quickly drop the tables in the db)

删除现有表（使用旧模式），进行初始迁移，然后再次应用。这将起作用（它对我有用），因为我们有一个“初始迁移”并且我们的数据库中没有同名的表。（提示：我曾经python manage.py migrate my-app-name zero快速删除数据库中的表）

Problem?You might want to keep the data in the existing table. You don't want to drop them and lose all of the data.

问题？您可能希望将数据保留在现有表中。您不想删除它们并丢失所有数据。

Solution 2:

解决方案2：

1. Create an initial migration with the same schema as the existing table, with these steps:

   • Modify your models.py to match with the current table in your database

   • Delete all files in "migrations"

   • Run python manage.py makemigrations your-app-name

2. Delete in django_migrations all the fields with django_migrations.app = your-app-name How to do this depends on which DB you are using Example for MySQL: delete from django_migrations where app = "your-app-name";

3. Modify your models.py to match the new schema (e.i. the schema that you need now)

4. Make new migration by running python manage.py makemigrations your-app-name

5. Run python manage.py migrate your-app-name

1. 使用与现有表相同的架构创建初始迁移，步骤如下：

   • 修改你的 models.py 以匹配你数据库中的当前表

   • 删除“迁移”中的所有文件

   • 跑 python manage.py makemigrations your-app-name

2. 使用 django_migrations.app = your-app-name 在 django_migrations 中删除所有字段如何执行此操作取决于您使用的数据库示例 MySQL： delete from django_migrations where app = "your-app-name";

3. 修改您的 models.py 以匹配新架构（即您现在需要的架构）

4. 通过运行进行新的迁移 python manage.py makemigrations your-app-name

5. 跑 python manage.py migrate your-app-name

This works for me. And I managed to keep the existing data.

这对我有用。我设法保留了现有数据。

More thoughts:

更多想法：

The reason I went through all of those troubles was that I deleted the files in some-app/migrations/ (the migrations files). And hence, those migration files and my database aren't consistent with one another. So I would try not modifying those migration files unless I really know what I am doing.

我经历所有这些麻烦的原因是我删除了 some-app/migrations/ （迁移文件）中的文件。因此，这些迁移文件和我的数据库彼此不一致。所以我会尽量不修改这些迁移文件，除非我真的知道我在做什么。

回答by Eosis

My issue was that there was no __init__.pyfile in the same folder as the migrations. On adding the __init__.pyto the folder which contained them, manage.py migratefound and ran them.

我的问题是__init__.py迁移所在的文件夹中没有文件。添加__init__.py到包含它们的文件夹后，manage.py migrate找到并运行它们。

回答by Leonardo Ramos

In my case I wrote like this:

就我而言，我是这样写的：

python manage.py makemigrations--emptyyourappname

python manage.py makemigrations- 空的yourappname

python manage.py migrate yourappname

python manage.py migrate yourappname

or:

或者：

Django keeps track of all the applied migrations in django_migrations table. So just delete all the rows in the django_migrations table that are related to you app like:

Django 在 django_migrations 表中跟踪所有应用的迁移。因此，只需删除 django_migrations 表中与您的应用程序相关的所有行，例如：

DELETE FROM django_migrations WHERE app='your-app-name'

DELETE FROM django_migrations WHERE app='你的应用名称'

and then do:

然后做：

python manage.py makemigrationspython manage.py migrate

python manage.py makemigrationspython manage.py migrate

回答by Vignesh

python manage.py migrate --fake APPNAME zero

This will make your migration to fake. Now you can run the migrate script

这将使您的迁移成为假的。现在您可以运行迁移脚本

python manage.py migrate APPNAME

Tables will be created and you solved your problem.. Cheers!!!

将创建表格，您解决了您的问题..干杯！！！

回答by WesternGun

@phanhuy152 has the best answer. Just to add my two cents:

@phanhuy152 有最好的答案。只是添加我的两分钱：

His solution is:

他的解决办法是：

1. Delete migration history in DB
2. Delete migrationsfolder
3. Edit your model to be consistent with DB before your change
4. makemigrationsto restore the initial state of the migration files
5. Then, change the model as you like
6. makemigrationsagain
7. migrateto apply updates to table.

1. 删除数据库中的迁移历史
2. 删除migrations文件夹
3. 在更改之前编辑您的模型以与 DB 保持一致
4. makemigrations恢复迁移文件的初始状态
5. 然后，根据需要更改模型
6. makemigrations再次
7. migrate将更新应用到表。

But in my case, I have several models in the models.pyfile and at the last step, Django complains about Table xxx already exists, because the initial migrations files intends to create the xxx table again, when we just don't (and don't want to)drop other tables.

但就我而言，我在models.py文件中有几个模型，在最后一步，Django 抱怨Table xxx already exists，因为初始迁移文件打算再次创建 xxx 表，而我们只是不（也不想）删除其他表。

In this case, in order to preserve the data, we must tell Django to leave them alone in migrate. We just do: (assume that class A is the one we change, and class B, C remain same):

在这种情况下，为了保留数据，我们必须告诉 Django 将它们单独留在migrate. 我们只是这样做：（假设类 A 是我们更改的类，而类 B、C 保持不变）：

models.py:

models.py：

from django.db import models

class A(models.Models):
    ...

class B(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

    ...

class C(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

Add these lines after we construct the initial migrations.

在我们构建初始迁移后添加这些行。

So, the process now is:

所以，现在的流程是：

1. ...
2. ...
3. ...
4. ...
5. Add managed = Falseto other classes
6. makemigrationsto apply Metachanges. You will see something like:

1. ...
2. ...
3. ...
4. ...
5. 添加managed = False到其他班级
6. makemigrations应用Meta更改。你会看到类似的东西：

output:

输出：

Migrations for 'backEnd':
  backEnd/migrations/0002_auto_20180412_1654.py
    - Change Meta options on toid
    - Change Meta options on tprocessasinc
    - Change Meta options on tservers
    - Change Meta options on tsnmpserver

1. migrateto apply them in DB
2. Change your model now: add a field, change the type, etc.
3. migrateagain.
4. Delete the Metaclass to let Django manage other class again. makemigrations, migrateagain.

7. migrate将它们应用到数据库中
8. 立即更改模型：添加字段、更改类型等。
9. migrate再次。
10. 删除Meta该类，让 Django 再次管理其他类。makemigrations，migrate再次。

Now you have all the structure and data of your models, without losing the part formerly stored in DB.

现在您拥有模型的所有结构和数据，而不会丢失以前存储在 DB 中的部分。

回答by Wolfgang Leon

The problem here are fake migrations somewhere. Basically in your database the table created from your model doesn't exist, tho somewhere in time that table existed before, due an old update o whatever it may be. The problem is that django already made those migrations so the tables MUST exist for hence overlooking migrations but getting error "table_doesnt_exist" in Admin.

这里的问题是某处的假迁移。基本上在您的数据库中，从您的模型创建的表不存在，尽管该表之前存在过某个时间，但由于旧更新，无论它可能是什么。问题是 django 已经进行了这些迁移，因此表必须存在，因此可以忽略迁移，但在 Admin 中出现错误“table_doesnt_exist”。

Solution:

解决方案：

1.- Make sure to save any data from that model.

1.- 确保保存该模型中的所有数据。

2.- Access your database and run this query.

2.- 访问您的数据库并运行此查询。

 SELECT * FROM django_migrations;

3.- Get the id from the list generated from the query. These are migrations that Django has migrated so far, hence TABLES MUST EXIST. In your case I'd look for a row named roadmapprofile, due this is the name of your model.

3.- 从查询生成的列表中获取 id。这些是 Django 到目前为止已迁移的迁移，因此 TABLES MUST EXIST。在您的情况下，我会查找名为roadmapprofile的行，因为这是您的模型的名称。

4.- Now lets delete this row from this table using the ids,

4.- 现在让我们使用 id 从这个表中删除这一行，

 DELETE FROM django_migrations where django_migrations.id in (value_id1, value_id2 ... value_idN);

Replace value_id1 and value_id2 with respective ids. It could be only one or many so don't worry if you don't see more than 1 id, what this means is that only one model exists under the current app.

用各自的 id 替换 value_id1 和 value_id2。它可能只有一个或多个，所以如果您没有看到超过 1 个 id，请不要担心，这意味着当前应用程序下只存在一个模型。

5.- Migrate app to zero

5.- 将应用程序迁移到零

 manage.py migrate <app_name> zero

6.- Delete all migrations files within the app migrations folder

6.- 删除应用程序迁移文件夹中的所有迁移文件

7.- Create Migrations

7.- 创建迁移

 manage.py makemigrations

8.- Once you delete these registries and run manage.py migrate; Django will be forced to run migrations for these models due "MIGRATIONS WON'T EXIST" for these models.

8.- 删除这些注册表并运行 manage.py migrate 后；由于这些模型的“迁移将不存在”，Django 将被迫为这些模型运行迁移。

 manage.py migrate

That's it. You shouldn't have any problems following these instructions. By the way, you shouldn't loose any data from other models due you're only migrating and updating tables related to these specific models.

就是这样。按照这些说明操作应该不会有任何问题。顺便说一下，您不应该丢失来自其他模型的任何数据，因为您只是迁移和更新与这些特定模型相关的表。

回答by Camila Andrade

I had this same problem. Make sure the app's migrations folder is created (YOURAPPNAME/ migrations). Delete the folder and enter the commands:

我有同样的问题。确保已创建应用程序的迁移文件夹 (YOURAPPNAME/ migrations)。删除文件夹并输入命令：

python manage.py migrate --fake
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial

I inserted this lines in each class in models.py:

我在models.py的每个类中插入了以下几行：

class Meta:
    app_label = '<app_name>'

This solved my problem.

这解决了我的问题。