Django 1.6 Models (II) — Manager

这段时间学习 django 使得项目开发变得异常低效,只是为了不在每次用到这些知识的时候才去百度,因为这样做出来的东西离优质的软件太远太远。

发现这个东西还是常用得很,必须先仔细啃掉。

Manager 类似于 Field,都是 models 模块里面的一个类;

不同的是,它不是字段,不是存放在数据库里面的实体,而是一个类似于“属性”的家伙,即返回一定方式的计算之后产生的内容,而且更好用的是,它可以在类或者 query_set 的层面调用,而不仅仅是在对象层面。

1. 默认 manager

如果在 models 类下面不去定义一个 manager,那么 objects 就是一个默认的 manager。但如果用下面的方式重新声明一个 manager,默认的 objects 就会失效:

from django.db import models

class Person(models.Model): #... people = models.Manager()

默认的 manager(包括通过 models.Manager() 产生的),实际上就是一个 select * from 的方式获取所有对象;我们可以创建自己的 manager,返回任意的东西;

2. 自定义 Manager

我们可以从 models.Manger 派生 Manager 类,然后为其声明方法;

self.model

当然,一个自定义的 Manager 也可以供多个 Models 去使用;

那么在 Manager 里面声明的方法里,self.model 就对应于 Manager 所在的 Model 类,可以通过 self.model(…) 来构造对象和应用其他对应的类方法;(这是一个很好的多态性。)

Manager.get_queryset()

Manager 的 get_queryset() 方法可以获取调用 Manager 的 queryset。重载此方法可以在默认 manager 的基础上进行操作,并返回一个 queryset 对象。

在一个 Model 里面使用多个 Manager

这种情况,第一个声明的 Manager 会被认为是默认 manager,会有一些特殊的性质(具体先不深究);因此 Manager 的次序也是需要讲究的。

manager 的继承特性
  1. 非 abstract 基类的 manager 不继承;
  2. abstract 基类的 manager 全部继承给子类;
  3. 子类的默认 manager 先查找第一个子类定义的 manager,没有的话查找 abstract 基类的第一个 manager,再没有就使用缺省 objects 作为默认 manager;
  4. abstract 基类的 manager 只能在子类调用,不能在基类直接调用。
use_for_related_fields

如果在 Manager 类里面设定这个字段为 True,那么在使用 rel_name 进行反向访问的时候,也会调用这个 manager 返回结果。


【转载请附】愿以此功德,回向 >>

原文链接:https://www.huangwenchao.com.cn/2014/03/django-models-2.html【Django 1.6 Models (II) — Manager】

发表评论

电子邮件地址不会被公开。 必填项已用*标注