django model建模 更改删除以及切换表 如果特殊字符，修改setting

当我们需要添加一个模型类或者修改模型类中的字段信息的时候，需要进行怎样的操作才能成功呢？没错，我们需要依次运行下面两个命令：

#创建要修改的内容文件
python manage.py makemigrations
#执行修改
python manage.py migrate

通过上面这两个命令我们就可以将模型类的创建和修改生效到数据库中，那么你有没有想过当我们依次执行这两个命令的时候，Django都发生了什么呢？下面我将用一个例子来讲解模型类的创建和删除的过程，以及在这个过程中Django都进行了哪些操作。

1.创建及修改
假如我们在model.py中新添加一个模型类Commit，并给这个类添加一个name字段，字段属性是CharField。在提交命令之前，我们观察一下三个地方：

1.看一下APP路径下的migrations文件夹下的文件，如果你之前已经进行过模型类的更新操作，那么此文件夹下面应该是这样的文件结构

该文件夹下前面有000x序号的文件记录的是我们每次更新数据库时的操作，每当我们进行一次操作的时候，该目录下机会生成一个带有序号的py文件。

2.再看一下数据库的django_migrations这个自动生成的表的内容，其中我们的app对应的记录有三条，这三条的记录的name字段和migrations文件夹下面的带有序号的三个文件是同名的。

3.最后看一下我们的数据库中的表，此时imooc这个APP下只有三张表：post、tag、test。这是我们之前生成的。

好了，看完之后我们在终端执行下面的命令，来生成修改的内容：

python manage.py makemigrations
我们得到了如下的反馈：

(wprkplace) D:\PythonProject\learn>python manage.py makemigrations
Migrations for ‘imooc’:
imooc\migrations\0004_commit.py:
- Create model Commit
此时我们再去migrations这个文件夹下面可以看到，django已经为我们生成了一个0004_commit.py的文件，这个文件记录了我们要修改的内容：

文件的代码如下：

from future import unicode_literals

from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
(‘imooc’, ‘0003_test’),
]
operations = [
migrations.CreateModel(
name=‘Commit’,
fields=[
(‘id’, models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name=‘ID’)),
(‘name’, models.CharField(max_length=100)),
],
),
]
重点主要在operations，代码的意思是说我们将要创建一个name=commit的模型类（数据表），然后创建一个name字段，它的字段属性为CharField，参数为max_length=100。需要注意的是，id字段是Django为我们自动创建的一个自增长的主键。

然后我们再看数据库中的表的数量是没有变化的，django_migrations这个表的内容也没有变化，这说明我们的修改还没有生效。然后我们执行下面这个命令，来使修改生效：

python manage.py migrate
这时，我们得到了如下的结果：

(wprkplace) D:\PythonProject\learn>python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, contenttypes, imooc, sessions
Running migrations:
Applying imooc.0004_commit… OK
然后我们就可以看到imooc数据库中多了一个imooc_commit的数据表，然后还可以看到django_migrations表中多了一条记录，这条记录记录了我们修改的是哪个应用下面的哪个文件。这时我们的模型类的修改操作就算是正式成功了！

2.删除操作
如果我们要删除一个模型类该怎样做呢？其实顺序也是跟我们创建一个模型类是一样的：

首先删除，模型类的代码
然后删除，migrations文件夹下面对应的操作记录文件
然后删除，django_migrations表中对应的生成记录
最后删除，数据库中的数据表
以上才是删除一个模型类的正确流程。

切换表

那么该如何将模型与数据库中的表映射呢?根据旧的数据库生成对应的ORM模型，需要以下几个步骤:

1、Django 给我们提供了一个inspectdb的命令，可以非常方便的将已经存在的表，自动的生成模型。想要使用inspectab自动将
表生成模型。首先需要在settings.py 中配置好数据库相关信息不然就找不到数据库。示例代码如下:

DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.mysql’,
‘NAME’: ‘database_name’,
‘HOST’: ‘127.0.0.1’,
‘PORT’: ‘3306’,
‘USER’: ‘your_database_name’,
‘PASSWORD’: ‘your_database_password’,
}
}

再通过 python manage.py inspectdb 就会将表转换为模型后的代码显示在终端。

不过以上代码只是显示在终端，如果想要保存到文件，可以指定重定向文件，比如输出到 models.py 文件中，需要执行：

python manage.py inspectdb > models.py

以上命令只能在终端中执行，不能在pycharm->Tools->Run manage.py Task…中使用

如果只想要转换一个表生成模型，可以执行以下语句：python manage.py inspectdb table_name > models.py

如果转化多个表，表名之间用空格隔开：
python manage.py inspectdb table_name tablename > models.py

2、修正模型:新生成的ORM模型有些地方可能不太适合使用。比如模型的名字，表之间的关系等等。那么以下选项还需要重新配置:
(1)、模型名:自动生成的模型，是根据表的名字生成的，可能不是你想要的。这时候模型的名字你可以改成任何你想要的。
模型所属app：根据自己的需要，将相应的模型放在对应的app中。放在同个app中也是没有任何问题的。只是不方便管
理。

 (2)、模型外键引用:将所有使用Foreignkey 的地方，模型引用都改成字符串。这样不会产生模型顺序的问题。另外，如果引用

的模型已经移动到其他的app中了，那么还要加上这个app的前缀。
(3)、让Django管理模型：将Meta下的managed=False 删掉，如果保留这个，那么以后这个模型有任何的修改，使用migrate都不会映射到数据库中。
(4)、表名：切记不要修改表的名字(这里的表名不是模型类名，而是class Meta: 中的db_table)。不然映射到数据库中，会发生找不到对应表的错误。

3、执行命令 *** python manage.py makemigrations *** 生成初始化的迁移脚本。方便后面通过ORM来管理表。在这时候还需要执行命令 python manage.py migrate --fake-initial，因为如果不使用–fake-initial，那么会将迁移脚本会映射到数据库中。这时候迁移脚本会新到建表，而这个表之前是已经存在了的，所以肯定会报错。此时我们只要将这个0001-initial 的状态修改为已经映射，而不真正执行映射，下次再migrate的时候，就会忽略他。

4、将Django的核心表映射到数据库中: Django中还有那些核心的表也是需要创建的。不然有些功能是用不了的。比如auth相关
表。如果过个数据库之前就是使用Django开发的，那么这些表就已经存在了，可以不用管了。如果之前这个数据库不是使用Django开发的，那么应该使用python manage.py migrate命令将Django中的核心模型映射到数据库中。

遇到的问题：django migrate 抛出异常：ValueError: Found wrong number (0) of constraints for …

问题描述：

修改了 Meta 的 unique_together 属性，makemigrations 的时候，能正常进行，但是当进行 migrate 的时候就抛出了 ValueError: Found wrong number (0) of constraints for …

解决办法：

参考自 https://stackoverflow.com/questions/41623515/received-valueerror-found-wrong-number-0-of-constraints-for-during-djan

因为修改了唯一约束索引，If you look at your actual table (use \d table_name) and look at the indexes, you’ll find an entry for your unique constraint. This is what Django is trying to find and drop. But it can’t find an exact match(Postgres and MySQL Answer)

找到在修改 unique_together 之前的包含 AlterUniqueTogether 的 migrations 所有文件，将上面的 unique_together 参数值，修改成与当前一致（增加或者删减，或者字段顺序）

修改完成以后，直接 migrate 即可。

如果特殊字符，修改django中的setting,
增加 ‘OPTIONS’: {‘charset’: ‘utf8mb4’},