ゴールデンストーンプロジェクトの最初のチャレンジに参加するために登録しました - 賞金プール 100,000 を共有します。これは私の n 回目の記事です。クリックしてイベントの詳細を表示します

I.はじめに

django でデータベースモデルを追加または変更する場合、通常、makemigrations を実行して移行し、モデルクラスに対応するデータベーステーブルを生成するか、対応するテーブル構造を変更する必要があります。これはとても便利です。

しかし、実際にこの 2 つのコマンドを実行すると、予期しないエラーが発生することがよくあります。次の 2 つのコマンドは、より落ち着いて使用できるように詳細に説明されています。

2. migrate と makemigrations の詳しい説明と実際の操作

1. 移行を行う

makemigrations は、作成したモデルのデータベース移行ファイルを生成します

たとえば、製品のモデルを作成します

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] ファイルを追加して構成し、そのアプリ名を INSTALLED_APPS に追加してください) ここに画像の説明を挿入。複数のアプリファイルがある場合は、ファイルを移行するアプリ名を指定します。生成、コマンドpython manage.py makemigrations [app_label]

通常、このコマンドで十分です。

もちろん、実行python manage.py makemigrations --dry-run --verbosity 3、移行ファイルを生成するコードなど、使用するコマンドは他にもあります。ここに画像の説明を挿入

python manage.py makemigrations --no-header移行ファイルは、django のバージョンと移行時間の注釈なしで生成できます。ここに画像の説明を挿入

対応するモデルコードに構成項目managed=Falseを追加して移行を無視し、モデルmakemigrationsの移行コードを生成せずに移行コードを実行できます。ここに画像の説明を挿入

他にもいくつかのコマンドがありますが、それらは一般的に使用されていません。公式ドキュメントを読んで理解することができます

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】表有了一条外键约束的记录ここに画像の説明を挿入

当我们对【project】表增加一条project_id为 1 的记录的时候，由于【product】表不存在相应的记录会导致报错: ここに画像の説明を挿入

可以看出，这个约束的存在，会保证表间数据的关系的完整性。更不容易出现脏数据。这是外键约束非常明显的优点！

但也存在着不可忽略的缺点：

性能问题

我们刚建立了两张表【project】和【product】，【project】表通过project_id字段与【product】表做了外键约束。

这个时候，当我们每次往【project】表插入数据的时候，它会先去【product】中查询是否有对应的关联数据，如果通过程序来控制可以不进行这次查询。但设立了外键约束，就一定会去进行该查询。这实际是冗余的。当关联的字段少的时候可能没啥影响，但一但关联字段多了后，这种影响就尤其明显！

死锁

在我们每次修改【project】数据时，都需要去【product】表检查数据,需要获取额外的锁。如果在高并发大流量的事务场景下，外键约束更容易造成死锁！

开发/测试效率的降低

在我们日常的测试过程中，经常会遇到发现了一个BUG想复现或者方便测试的情况，会直接改数据库表的数据来达到方便测试的效果。

虽然这及不规范，但实际情况就是能够提升我们很多效率。这是毋庸置疑的！可是，这样的操作也会带来一些问题，比如因为数据导致的BUG，但实际并不是程序的BUG，或者发现不了一些潜在的BUG。

所以我的建议是：如果是业务相对复杂的话，可以在测试环境使用外键约束，但上了生产环境需要去掉！如果业务相对简单，那完全可以删除外键约束！

在django中，即便你删除了数据库中的外键约束，只要你model代码里的外键关系还在，则还是可以使用它的ORM进行外键操作的，没有区别！

四、反向迁移-inspectdb

inspectdb 命令会检查你的settings文件指向的数据库，将其数据库表生成对应的django模型代码并打印出来ここに画像の説明を挿入

也可以inspectdb指定的模型 inspectdb product ここに画像の説明を挿入

Django の Migrate と Makemigrations の説明