Django可能遇到的问题

1. 出现莫名其妙的 app01

我项目中的app名字并不是app01，可是运行python manage.py makemigrations的时候总是提示app01不是已安装的app

Applying admin.0003_auto_20180701_0233...Traceback (most recent call last):   FiApplying admin.0003_auto_20180701_0233...Traceback (most recent call last):   Field ...

解决办法：

找到自己的python环境下的site-packages/django/contrib/admin/migrations，把里面的py文件全删掉即可。

2. 使用了自定义的auth表，结果建表的时候提示admin找不到某个字段

类似以下报错...

django.core.exceptions.FieldDoesNotExist: model has no field named <id>

解决办法：

找到自己的python环境下的site-packages/django/contrib/admin/migrations，把里面的py文件全删掉即可。

3. 点击页面的按钮绑定AJAX提交数据但是后端收不到任何数据

这种情况一般是form表单中使用了 <button>提交</button>按钮，但是<button>< button/>按钮中没有明确指定type="button"。

解决办法：

使用AJAX提交数据的时候，提交数据的按钮可以使用如下方式：

1. 使用最保险的input标签，并且指定type类型为button

<form>
    ...
    <input type="button" value="提交">
</form>

2. 既然使用ajax提交数据就没必要再写form标签。

直接用div包裹获取用户输入的input标签即可。

3. 使用button按钮的时候，明确指定type类型为button， type一定不能省！！！

<button type="button">提交</button>

Django生成数据表时报错

1 WARNINGS:
2 ?: (mysql.W002) MySQL Strict Mode is not set for database connection 'default'
3         HINT: MySQL's Strict Mode fixes many data integrity problems in MySQL, such as data truncation upon insertion, by escalating warnings into errors. It is strongly recommended you activate it. See: https://docs.djangoproject.com/en/1.11/ref/databases/#mysql-sql-mode

解决方法：

在settings.py里数据库位置添加：

 'OPTIONS': {
             'init_command': "SET sql_mode='STRICT_TRANS_TABLES'"
 {

慎用django orm的update_or_create方法

根据错误日志，发现产生死锁的有4个接口。这4个接口中，阅读业务代码，发现均有使用update_or_create。

为什么update_or_create方法会造成死锁呢？通过阅读源码

发现，update_or_create是使用了事务with transaction.atomic(using=self.db)并select_for_update。而mysql事务中，FOR UPDATE中的WHERE筛选语句如果有查询没有索引字段或者索引未生效，将产生表锁，否则将产生行锁（参考https://www.cnblogs.com/wangshiwen/p/9837408.html）。

　　阅读事故日志4个接口的代码中使用的update_or_create中涉及到的查询，发现索引字段。因此每个接口请求将锁住业务涉及到的表，而短时间大量用户涌入造成了MySQL死锁的产生。

参考：

https://haicoder.net/note/mysql-interview/mysql-interview-mysql-select-for-update.html

https://www.cnblogs.com/jpfss/p/9225453.html

https://www.cnblogs.com/wangshiwen/p/9837408.html

Django时间时区问题

在django1.4以后，存在两个概念

naive time 与 active time。

简单点讲，naive time就是不带时区的时间，Active time就是带时区的时间。

举例来说，使用datetime.datetime.utcnow()、datetime.datetime.now()输出的类似2015-05-11 09:10:33.080451就是不带时区的时间（naive time），

而使用django.util.timezone.now()输出的类似2015-05-11 09:05:19.936835+00:00的时间就是带时区的时间（Active time），其中+00:00表示的就是时区相对性。

另外一个概念UTC时间，UTC时间表示的是格林尼治平均时即可，即零区时间。而北京时间表示的是东八区时间，即UTC+8。

下面列出了几个常见的时区问题

问题一：三个时间datetime.datetime.now()、datetime.datetime.utcnow()与django.util.timezone.now()的区别

datetime.datetime.now()：输出的永远是本地时间（naive time）与配置无任任何关系。

datetime.datetime.utcnow()：如果setting中配置USE_TZ=True则输出的是UTC时间（naive time），如果setting中配置USE_TZ=False，则该输出时间与datetime.datetime.now()完全相同。

django.util.timezone.now()：如果setting中配置USE_TZ=True则输出的是UTC时间（active time），如果配置USE_TZ=False，则与datetime.datetime.now()完全相同。

问题二：django存储到数据库的时间比本地时间小8个小时？

首先要明确的一点，Django1.4版本之前，对时区毫无概概念，对时间的存取、展示不做任何处理，数据库里存储的通常是本地时间，当然都是naive time。

Django在1.4版本之后存储如果设置了USE_TZ=True，则存储到数据库中的时间永远是UTC时间。这时如果settings里面设置了USE_TZ=True与TIME_ZONE = 'UTC'，用datetime.datetime.now()获取的时间django会把这个时间当成UTC时间存储到数据库中去。如果修改设置为USE_TZ=True与TIME_ZONE = 'Asia/Shanghai'，用datetime.datetime.now()获取的时间由于不带时区，django会把这个时间当成Asia/Shanghai时间，即东八区时间，然后django会把这个时间转成带时区UTC时间存储到数据库中去，而读的时候直接按UTC时间读出来，这就是网上很多人遇到的存储到数据库中的时间比本地时间会小8个小时的原因。

问题三：DateTimeField role_cost_history.cost_time received a naive datetime （2015-05-12 19:59:01.259517) while time zone support is active？

这个问题是因为如果设置了USE_TZ=True之后，model里面认为DateTimeField使用UTC时间（带时区的时间），这时用datetime.datetime.now()获取的时间是不带时区的就会报这个问题。

问题四：django.util.timezone.now()输出时间比本地时间小8个小时

只要设置了USE_TZ=True，django.util.timezone.now()输出地永远是UTC时间，不管你设置的TIME_ZONE是什么。如果USE_TZ=False，则django.util.timezone.now()输出等同于datetime.datetime.now()，也不管TIME_ZONE设置的是什么。

问题五：模板显示时间

在设置了USE_TZ=True之后，如果设置了TIME_ZONE = 'Asia/Shanghai'，尽管数据库中存储的是UTC时间，但在模板显示的时候，会转成TIME_ZONE所示的本地时间进行显示。

建议：为了统一时间，在django开发时，尽量使用UTC时间，即设置USE_TZ=True，TIME_ZONE = 'Asia/Shanghai'，并且在获取时间的时候使用django.util.timezone.now()。因为后台程序使用时间时UTC时间就能满足，也能保证证模板时间的正确显示。