首页>>后端>>Python->django模型怎么这么难用(Django 模型)

django模型怎么这么难用(Django 模型)

时间:2023-12-09 本站 点击:0

导读:很多朋友问到关于django模型怎么这么难用的相关问题,本文首席CTO笔记就来为大家做个详细解答,供大家参考,希望对大家有所帮助!一起来看看吧!

在Django模型可能的错误问题,怎么解决

虽然你可能会失望,但是不得不告诉你,因致命错误导致的问题,只要打不开就绝对不可修复了,遇到过不只6次了,有的时候能打开,就算是打开了,绝对是你需要的那部分是没有了,你不需要的地方有可能还在。这就需要平时在制作过程中每个步骤经常保存的习惯。

django(python)的模型字段类的实例化问题,新手请教。

这些东西,都有办法。我都用过。不过,最近不用了。我只能给你一个指引。

在django提供的管理类里admin有所有这些用法。你可以找到它的源代码,自己读一下。

DataField的确需要一个这样的对象来给它才可以向数据库写。

ForiegnKey也的确需要一个已建立好的class。 比如ForiegnKey(anotherModel), anotherModel一定是一个已定义好的class

另外在djangoproject的官网中有丰富的帮助。大部分答案都可以搜索到。

Django模型(三)

知识要点:

表关系的实现

一对多表关系

在Mysql中一对多是通过外键实现的,在django模型中通过ForeignKeyfield类型实现。

一对一表关系

在Mysql中一对一是通过外键加唯一键实现的,在django模型中通过OneToOneField类型实现。

多对多表关系

在Mysql中多对多是通过中间表外键加联合唯一键实现的,在django模型中通过ManyToManyField类型实现。中间表模型会自动帮我们创建好。

例子:

关系表中数据的操作

话说Django orm模型为什么比原生的mysqldb慢

首先确认下mysql索引问题.

进入mysql,查看索引情况 , 命中索引.

mysql explain SELECT sum(idate_count) FROM buzz_keyword_historyWHERE ( buzz_keyword_history . date  ’2015-09-20 00:00:00′ ANDbuzz_keyword_history . date = ’2015-09-01 00:00:00′ ANDbuzz_keyword_history . value = ‘手机’);

+—-+————-+———————-+——+——————————–+———-+———+——-+——+————————————+

| id | select_type | table                | type | possible_keys                  | key      | key_len | ref   | rows | Extra                              |

+—-+————-+———————-+——+——————————–+———-+———+——-+——+————————————+

|  1 | SIMPLE      | buzz_keyword_history | ref  | in_value,in_idate,search_speed | in_value | 182     | const | 1514 | Using index condition; Using where |

+—-+————-+———————-+——+——————————–+———-+———+——-+——+————————————+

1 row in set (0.00 sec)

然后在看了下mysql服务器的负载情况,load特别的底下.

Python

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

          2.80    0.00    1.22    0.41    0.00   95.57

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util

sdc               0.00   808.61   21.65   27.02  5531.93  6685.05   251.00     0.55   11.39   0.71   3.45

sdb               0.00   126.81    3.30    4.95   823.13  1054.05   227.75     0.37   44.44   1.50   1.24

sda               0.06   215.50    2.46    7.87   599.12  1786.94   231.10     0.81   78.76   1.37   1.41

memdiska          0.00     0.00  585.63 2638.44 84515.95 21107.53    32.76     0.15    0.05   0.03   8.54

dm-0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    4.39   1.13   0.00

接着在mysql server开启了慢查询及sql语句调试模式,发现slow.log没有特别的日志…都是跟本业务无关的慢查询.

整个页面的静态文件也是加载正常,速度也是给力,虽然在nginx里没有配置强制缓存… 但为毛数据加载这么慢 ,为毛 ?

最后不得不重新怀疑mysql查询,我们开始统计整个django orm语句消耗的时间,一看非常的惊人,居然消耗了6秒的时间… 原本以为django 的orm只是帮助我们做了sql语句的映射,说实话我以前还真的就这么想。

Python

run_func.objects.filter(date__gte=d[0], date__lt=d[1],value=value).aggregate(Sum(idate_or_cdate + '_count'))

又看了django orm model的介绍,这django模型不简单呀,他的返回值是querysets类型。 也就是说,他会把orm执行的结果,转换成queryset结构 。 就因为这样被封装,所以我们每次用orm感觉特别友好的原因。

解决的方法,直接走原生的mysql sql语句,在python下你的选择 mysqldb,也可以用django的connection。推荐用connection,因为大家的db地址配置都是放在settings.config里面的。

下面是django 运行原始sql语句的方法,大家参考下..

Python

from django.db import connection, transaction

import MySQLdb

.......

cursor = connection.cursor(cursorclass = MySQLdb.cursors.DictCursor)

cursor.execute(sql,None)

如果你有多个数据库,可以在connections选择数据库。

from django.db import connections

cursor = connections['xiaorui'].cursor()

transaction.commit_unless_managed(using='xiaorui')

最终的结果,使用原生的sql语句用了不到1秒,而用django的orm是6秒左右..   快了好几倍…

我觉得django orm应该多加个是否要转换成queryset的参数,这样我们根据需求来进行配置。  下面是我用django debug的结果.. 可以看到速度提升了不少.

django自动生成model模型映射表时候发生异常

在网上看到都是使用Django的models和makemigration,migrate命令来创建新表,并使用。可是我的数据已经存在了已经创建好,并且已经存储有数据了,不能再重新创建新表了。了解Django的表明和models名称的映射关系就可以让Django使用已经存在的表。

假如在Django存在models如下:

[python] view plain copy

from django.db import models

# Create your models here.

class Sciencenews(models.Model):

id = models.CharField(max_length=36,primary_key=True)

first_module = models.CharField(max_length=30,default="News")

second_module = models.CharField(max_length=30,default="Latest News")

title = models.CharField(max_length=300)

author = models.CharField(max_length=60,null=True)

publish_date = models.CharField(max_length=35,null=True)

content = models.TextField(null=True)

crawl_date = models.CharField(max_length=35,null=True)

from_url = models.CharField(max_length=350,null=True)

执行数据迁移命令:

[python] view plain copy

python manage.py makemigration

python manage.py migrate

会在数据库中生成名称为show_sciencenews的数据表。show为应用名称,此处我的应用名称为show。可以看到Django创建表的命名规则:应用名_模型名。

我的存储爬取到的数据的表格名称原来为science_news,想要Django使用它,而不是创建新的表,只需要把的它的名称改为:应用名_要与该表映射的models名称,在此处我改为show_sciencenews。然后使用如上的数据迁移命令,这时可能会提示数据表已经存在的错误,不用理会,models已经和数据表映射上了。接下来只需要正常使用models和数据表就可以了。

为什么django模型层的null和blank约束不起作用

null: If True, Django will store empty values as NULL in the database. Default is False. 如果为True,空值将会被存储为NULL,默认为False。 blank: If True, the field is allowed to be blank. Default is False. 如果为True,字段允许

结语:以上就是首席CTO笔记为大家介绍的关于django模型怎么这么难用的全部内容了,希望对大家有所帮助,如果你还想了解更多这方面的信息,记得收藏关注本站。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/Python/20760.html