解决Django数据库makemigrations有变化但是migrate时未变动问题

写models.py时缺少了一个 verbose_name,导致数据库出现问题,整了很久,摸索出重新建立数据库的方法:

首先删除每个app中的migrations中的除了init.py的文件,在数据库中清空所有的表,然后执行migrate,这时会自动生成系统默认的那些表,然后执行makemigrations,再执行migrate

如果只是众多应用中的一个出了问题的话,删除与之相关的表,然后进入django_migrations表中,将相应的app那项记录删除,然后再执行

makemigrations appname
migrate

django_migrations表的作用:

在执行makemigrations后,会在app的migrations目录生成一个带有编号的py文件,这就是记录的数据库的变动和操作,当执行migrate后,django_migrations就会将上面生成的py文件记录下来,类似一个日志记录

初始的(只有自带的app时)表:

django_migrations中的初始内容如下:

以上这篇解决Django数据库makemigrations有变化但是migrate时未变动问题就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 浅谈Django学习migrate和makemigrations的差别

    本文主要研究的是Django中migrate和makemigrations的差别,具体如下. 在你改动了 model.py的内容之后执行下面的命令: Python manger.py makemigrations 相当于 在该app下建立 migrations目录,并记录下你所有的关于modes.py的改动,比如0001_initial.py, 但是这个改动还没有作用到数据库文件 你可以手动打开这个文件,看看里面是什么 在此之后执行命令 python manager.py migrate 将该改

  • 解决Django migrate No changes detected 不能创建表的问题

    起因 修改了表结构以后执行python3 manage.py migrate 报错: django.db.utils.OperationalError: (1091, "Can't DROP 'email'; check that column/key exists") 所以进数据库把对应的表删除了,想着重新生成这张表. 删除表以后执行: python3 manage.py makemigrations python3 manage.py migrate 还是不能生成表,提示:No c

  • 解决Django migrate不能发现app.models的表问题

    有时候运行Django的migrate命令不能创建INSTALLED_APPS中的app中的models.py的数据库表, 这时可以先运行: python manage.py makemigrations [appname] 这里的appname是指你需要指定django检查的app name, 运行该命令后, 即可生成迁移文件, 最后运行: python manage.py migrate 以上一般可以解决问题, 如果还是有创建表格不全等问题的话, 可以将migrations文件, 数据库表,

  • django数据库migrate失败的解决方法解析

    Django是一个MVC架构的web框架,其中,数据库就是"Module".使用这种框架,我们不必写一条SQL语句,就可以完成对数据库的所有操作.在之前的Django版本中,我们像操作本地对象那样操作数据对象,在更改保存之后,执行python manage.py syncdb命令来同步数据库,在我使用的1.9.2版本中,需要依次执行一下步骤: python manage.py makemigrations (这个命令会根据你对数据库做出的更改生成操作数据库的python脚本) pyth

  • 解决django同步数据库的时候app models表没有成功创建的问题

    问题描述: 在django中创建了一个app,而且在app中自定义创建了几个数据表,在同步的时候系统自带的表可以成功,但是models中的没有生效,而且进入对应app下的migrations目录,发现为空,应该如何解决呢! 解决方式: python3 manage.py makemigrations --empty managerbook  # managerbook就是你的app名字,此处要写成自己的app名字 python3 manage.py makemigrations   # 再次正常

  • 解决Django删除migrations文件夹中的文件后出现的异常问题

    migrate文件记录了每一次数据迁移的改变 解决方法:重建数据库 1.删除数据库 错误方法: python manage.py shell from app.models import *Product.objects.raw('drop database') 上面删除数据库的方法是错误的 正确方法: 如果是用默认的sqlite数据库:可以直接右键,将db.sqlite3删掉. 如果用的其他数据库,则进入数据库的控制台,将数据库删掉 2.删除migrations中的文件,只保留__init__

  • 解决Django数据库makemigrations有变化但是migrate时未变动问题

    写models.py时缺少了一个 verbose_name,导致数据库出现问题,整了很久,摸索出重新建立数据库的方法: 首先删除每个app中的migrations中的除了init.py的文件,在数据库中清空所有的表,然后执行migrate,这时会自动生成系统默认的那些表,然后执行makemigrations,再执行migrate 如果只是众多应用中的一个出了问题的话,删除与之相关的表,然后进入django_migrations表中,将相应的app那项记录删除,然后再执行 makemigratio

  • 关于django 数据库迁移(migrate)应该知道的一些事

    命令 首先数据库迁移的两大命令: python manage.py makemigrations & python manage.py migrate 前者是将model层转为迁移文件migration,后者将新版本的迁移文件执行,更新数据库. 这两中命令调用默认为全局,即对所有最新更改的model或迁移文件进行操作.如果想对部分app进行操作,就要在其后追加app name: $ python manage.py makemigrations app_name $ python manage.

  • 解决django框架model中外键不落实到数据库问题

    在外键字段的参数中添加db_constraint=False即可,数据库中没有外键关系,代码中依然可以按照正常外键方式使用. 例如: class User(models.Model): name = models.CharField(max_length=255) room = models.ForeignKey(Room, db_constraint=False) class Room(models.Model): status = models.IntegerField(default=1)

  • 解决django migrate报错ORA-02000: missing ALWAYS keyword

    错误信息 PS D:\parttime\python\django\guanxiangzhiji> python manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, sessions Running migrations: Traceback (most recent call last): File "D:\app\anaconda\lib\site-packa

  • 解决Django no such table: django_session的问题

    操作系统:Win7 IDE:PyCharm4.5.3 Django:1.10.1 报错代码:request.session['key'] = value 描述:今天第一次使用Django中的session,只要出现"session['key']"就会报错. 解决方法: 1. 进入cmd,通过cd命令进入到项目根目录下,即manage.py文件所在的文件夹. 2. 看一下Django的版本号(我的是1.10.1), 1.9之后的执行'python manage.py migrate'命令

  • 解决django 向mysql中写入中文字符出错的问题

    之前使用django+mysql建立的一个站点,发现向数据库中写入中文字符时总会报错,尝试了修改settings文件和更改数据表的字符集后仍不起作用.最后发现,在更改mysql的字符集后,需要重建数据库,才能起作用. 这里完整记录一下解决方案 首先更改mysql的字符集 ubuntu下找到/etc/mysql/my.cnf   在最后添加 [mysqld] character-set-server=utf8 [client] default-character-set=utf8 [mysql]

随机推荐