django migration

django migration

https://docs.djangoproject.com/en/3.2/topics/migrations/

Migrations are Django’s way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database schema. They’re designed to be mostly automatic, but you’ll need to know when to make migrations, when to run them, and the common problems you might run into.

The Commands¶

There are several commands which you will use to interact with migrations and Django’s handling of database schema:

• migrate, which is responsible for applying and unapplying migrations.
• makemigrations, which is responsible for creating new migrations based on the changes you have made to your models.
• sqlmigrate, which displays the SQL statements for a migration.
• showmigrations, which lists a project’s migrations and their status.

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.

The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

https://zeddrix.com/wp-content/uploads/2020/03/Screen-Shot-2020-03-12-at-1.32.08-PM-960x540.png

根据model同步数据库内容。

migration文件生成

根据 当前所有的migrations， 生成当前数据库中应该有的 数据表 schema， 然后将 当前的 模型生成 schema进行对比， 产生本次的 migration文件。

https://tse1-mm.cn.bing.net/th/id/R-C.b9d4bc2250e4daec1e37b14b11b9ac41?rik=WRPEBNm2VrXhcQ&riu=http%3a%2f%2fblog.dusaiphoto.com%2fmigration_workflow.jpg&ehk=aYss%2bBDA2mPJGgVXtxtAqwGZULGQGE1jc2WwbL5%2fk%2fI%3d&risl=&pid=ImgRaw&r=0

https://www.kawabangga.com/posts/3647

migrate同步数据库过程

https://realpython.com/digging-deeper-into-migrations/#how-django-knows-which-migrations-to-apply

如果已经执行过migrate命令，再次执行，则会报没有改变。 为啥？

Let’s recap the very last step of the previous article in the series. You created a migration and then applied all available migrations with python manage.py migrate. If that command ran successfully, then your database tables now match your model’s definitions.

What happens if you run that command again? Let’s try it out:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  No migrations to apply.

Nothing happened! Once a migration has been applied to a database, Django will not apply this migration to that particular database again. Ensuring that a migration is applied only once requires keeping track of the migrations that have been applied.

因为数据库中存储了一个表， 专门用于migrations操作，其中记录了 每个表 应用过的 所有migrations 文件。

所以再次执行， 会拿migration文件名 跟数据库表中 应用过的 migration 文件名比较， 如果存在， 则跳过此migration文件。

Django uses a database table called django_migrations. Django automatically creates this table in your database the first time you apply any migrations. For each migration that’s applied or faked, a new row is inserted into the table.

For example, here’s what this table looks like in our bitcoin_tracker project:

ID	App	Name	Applied
1	contenttypes	0001_initial	2019-02-05 20:23:21.461496
2	auth	0001_initial	2019-02-05 20:23:21.489948
3	admin	0001_initial	2019-02-05 20:23:21.508742
4	admin	0002_logentry_remove...	2019-02-05 20:23:21.531390
5	admin	0003_logentry_add_ac...	2019-02-05 20:23:21.564834
6	contenttypes	0002_remove_content_...	2019-02-05 20:23:21.597186
7	auth	0002_alter_permissio...	2019-02-05 20:23:21.608705
8	auth	0003_alter_user_emai...	2019-02-05 20:23:21.628441
9	auth	0004_alter_user_user...	2019-02-05 20:23:21.646824
10	auth	0005_alter_user_last...	2019-02-05 20:23:21.661182
11	auth	0006_require_content...	2019-02-05 20:23:21.663664
12	auth	0007_alter_validator...	2019-02-05 20:23:21.679482
13	auth	0008_alter_user_user...	2019-02-05 20:23:21.699201
14	auth	0009_alter_user_last...	2019-02-05 20:23:21.718652
15	historical_data	0001_initial	2019-02-05 20:23:21.726000
16	sessions	0001_initial	2019-02-05 20:23:21.734611
19	historical_data	0002_switch_to_decimals	2019-02-05 20:30:11.337894

As you can see, there is an entry for each applied migration. The table not only contains the migrations from our historical_data app, but also the migrations from all other installed apps.

The next time migrations are run, Django will skip the migrations listed in the database table. This means that, even if you manually change the file of a migration that has already been applied, Django will ignore these changes, as long as there’s already an entry for it in the database.

You could trick Django into re-running a migration by deleting the corresponding row from the table, but this is rarely a good idea and can leave you with a broken migration system.

https://www.jianshu.com/p/aa6f0c13dab5

同步表的过程中，我手动将数据库中的一个表删除了，此时再去执行命令，发现不能再数据库中新建表了
修改了表结构以后执行python3 manage.py migrate 报错: