Django中Migrate和Makemigrations实操详解

Gail ·

更新时间:2024-11-01

· 741 次阅读

一、前言

二、migrate和makemigrations详解和实操

1. makemigrations

2. 在协同开发的情况下，有冲突的迁移文件时如何解决？

3. migrate

4. 迁移报错怎么办？

三、迁移生成的外键约束有必要吗

四、反向迁移-inspectdb

一、前言

当我们在django中添加或修改了数据库model后，一般需要执行makemigrations、migrate把我们的model类生成相应的数据库表，或修改对应的表结构。这是非常方便的。

但我们在实际使用中执行这两个命令经常会出现意向不到的报错。下面为你详细讲解这两个命令，让你更从容的使用他们！

二、migrate和makemigrations详解和实操 1. makemigrations

makemigrations会把我们写的model生成数据库迁移文件

比如我们建立一个一个Product的模型

class Product(models.Model):
    id = models.AutoField(primary_key=True)
    key = models.CharField(max_length=255)
    created = models.DateTimeField()
    suite_id = models.IntegerField(blank=True, null=True)
    report_version_id = models.IntegerField(null=True)
    class Meta:
        db_table = 'client'

然后执行命令python manage.py makemigrations会生成迁移文件(如果没有生成迁移文件，记得添加【apps.py】文件并配置，再将其app名称加入INSTALLED_APPS中)

如果我们有多个apps的文件可以指定app名称进行迁移文件的生成，命令

python manage.py makemigrations [app_label]

一般我们使用这个命令就够了！

当然还有其他命令给我们使用比如执行

python manage.py makemigrations --dry-run --verbosity 3

生成迁移文件的代码

可以使用 python manage.py makemigrations --no-header

生成不带django版本和迁移时间注释的迁移文件

我们可以在对应的model代码中加入配置项managed=False来忽略迁移这个时候再执行makemigrations的时候则不会对该model进行迁移代码的生成！

还有一些其他命令，但都不常用，可以阅读官方文档了解

2. 在协同开发的情况下，有冲突的迁移文件时如何解决？

在类似于使用git做协同开发时，我们应该有一个规范就是团队中的每一个人都应该避免修改同一个model文件。但不可能保证每次的提交都能避免 migrations 的冲突！

这个时候我们可以使用python manage.py makemigrations --merge进行合并来自动修复冲突，但这只适用于简单的model冲突合并。如果太复杂了建议阅读django的【writing-migrations】部分进行手动修改迁移文件

3. migrate

将迁移文件集同步到数据库中.

如果想指定某个app迁移的话可以使用

python3 manage.py migrate [app_label]

如果想指定某个migrations文件的话可以使用

python3 manage.py migrate [app_label] [migration_name]

例如：python manage.py migrate cases 0011_auto_20220726_1440

在我们使用django-admin startproject创建一个项目时后，如果需要使用django 的用户管理、数据库迁移等功能时就还需要配置好数据库连接，然后执行migrate

数据库会生成这些表

在表【django_migrations】中会记录每次的mirage记录。

有个问题是，我们的项目并没有迁移文件，那migrate是走哪拿到迁移文件进行迁移的呢？

我们可以在【C:\Users\电脑用户名\AppData\Local\Programs\Python\Python39\Lib\site-packages\django\contrib\auth\migrations】下找到自带的用户模型迁移文件。

我们还可以加参数 --database DATABASE 来指定迁移的数据库

也可以使用--plan 显示将要执行的迁移计划

4. 迁移报错怎么办？

有些时候，我们直接对数据库表字段进行了修改操作，而没有修改对应的model代码时，再执行makemigrations 、migrate会报错！

类似如下操作：

1）我们直接在数据库表中删除key这个字段

2）然后在对应的model代码中删除【key】这个字段

3）这个时候再执行makemigrations 、migrate，会发现migrate的时候报错了

报错的原因是我们先在数据库中删除了key这个字段，然后去修改的model文件进行迁移文件的生成和迁移。当migrate的时候会执行删除key这个操作，但我们的表里面已经没有这个字段了，所以会报错！

当遇到这种情况的时候，我们可以使用migrate --fake 来进行修复。

它会将将向目标的迁移操作标记为已应用，但不实际运行 SQL 来更改数据库结构。

另外使用migrate --fake-initial可以对具有由CreateModel(建表操作)的迁移操作时，如果数据库表已经存在，则允许 Django 跳过应用程序的初始迁移。此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用。但是，此选项不会检查匹配表名称之外的匹配数据库架构，因此只有在您确信现有架构与初始迁移中记录的架构匹配时才可以安全使用！

还有的其他命令操作不常用，需要了解可以参考官方文档

三、迁移生成的外键约束有必要吗

如果有外键的情况下，通过migrate 会在数据库中建立相应的外键约束。这是一个很不错的功能。在学校老师教学时，也会要求我们建立外键约束。

但在实际应用中并不是一个好的选择，而且在《阿里Java开发规范手册》中也明确规定：【强制】不得使用外键与级联，一切外键概念必须在应用层解决

为什么要做这样的规定呢？我们可以举一个例子来说明：

现在我们建立了两个Model：【product和project】，【project】的porduct字段，关联Product

class Product(models.Model):
    id = models.AutoField(primary_key=True)
    created = models.DateTimeField()
    product_name = models.CharField(max_length=100, null=True)
    class Meta:
        db_table = 'product'
class Project(models.Model):
    id = models.AutoField(primary_key=True)
    product = models.ForeignKey(to=Product, on_delete=models.PROTECT)
    project_name = models.CharField(max_length=100, null=True)
    class Meta:
        db_table = 'project'

然后我们进行迁移修改数据库表

可以看到【project】表有了一条外键约束的记录