问题描述:
  已有的model,修改之后 ,想重新建模,于是将migrations文件夹中除__init__.py之外其他文件都删掉,再次执行以下步骤python manage.py makemigrations确认成功 ,执行python manage.py migrate,提示No migrations to apply. 表示一脸懵逼。再次修改,指定表名 ,再次尝试,发现问题依旧,表示二脸懵逼

排查过程
  python manage.py dbshell 进到数据库里面 ,查看是否表已存在
  结果:表不存在
  检查migrations文件
  结果:文件没问题
百度 google 各种搜,乱投医,各种尝试
解决方案
  python manage.py dbshell 进到数据库中 ,执行delete from django_migrations where app='your_appname';
  python manage.py makemigrations(若migrations文件未删除 ,可不执行这一步)
  python manage.py migrate 好啦,大功告成
原因分析
  查看django_migrations表结构
建表语句:
  CREATE TABLE "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL);
原因
  造成多次应用migrations失败的原因是,当前model是修改过的 ,原来的migrations已经被我删除,但是,重新生成的migrations使用递增整数记名 ,所以,在django_migrations表中0001,0002等前面几个数字的文件都已被记录 ,在Django看来,被记录了就相当于已应用,所以 ,会出现刚开始的No migrations to apply.
避免方案
  有强迫症删除migrations文件的同学(比如我),请同时到数据库中删除相应记录
  没有强迫症的同学,可以继续生成新的migrations ,旧的就不必理会了
题外话
  执行python manage.py migrate之后 ,可以使用python manage.py sqlmigrate appname migrations_num(例如python manage.py sqlmigrate user 0002)查看当前migrations文件对应的sql语句。
另外,在使用上述命令查看0002文件的sql语句时发现,django会新建一个表user_new ,然后插入user表中的数据,再把user表删掉,再把user_new重命名为user 。所以 ,修改model的时候,不必担心原有数据会丢失。
————————————————
版权声明:本文为CSDN博主「Jessie-via」的原创文章,遵循CC 4.0 BY-SA版权协议 ,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/_25730711/article/details/60327344

文章来源于网络,如有侵权请联系站长QQ61910465删除
本文版权归趣快排SEO www.SeogurUblog.com 所有,如有转发请注明来出,竞价开户托管,seo优化请联系QQ▶61910465