DRF更多知识

关于自定义异常

在dispatch中首先对request对象进行了封装，然后进行进行三大认证，在此期间可能会发生异常，捕获异常后:handler_exception,然后get_exception_handler()，这个方法返回settings.Exception_Handler,也就是说默认使用的是rest_framework.views.exception_handler,所以我们在app中创一个异常py文件，需要返回一个响应，将rest_framework.views.exception_handler导入，在自己写的函数中执行这个函数，得到一个响应，本来这个函数可能会返回None，这里判断一些，如果是None，就构造一个响应信息{'detail':'服务器错误}，然后Response（响应信息，status =500）。将这个响应返回。

然后全局配置中使用这个配置：方法可以参考defsettings文件，双shift查找settings，找到异常信息的键，然后将值改为自己的方法。

关于自定义的User类

自定义User类的时候继承的是Abstract_User,而不是User,虽然User继承Abstract_User，并且类中什么都没干，但是Abstract表中Meta中abstract = True，这个表示在类被访问时也不会去数据库中创建表。

作为基类，一定在Meta中要有abstract字段

设置自定义User类，在settings中AUTH_USER_MODEL = 'app名字.用户类模型名'

类与类之间的关系比较复杂时，可以把表之间的链接不交给数据库，直接通过逻辑实现 表之间的链接

• 实现：db_constraint 关闭表连接，on_delete删除时的操作，可以是set_default,可以使set_NULL,还用重要的related_name = 'detail' 用于反向查找

class Author(BaseModel):
    name = models.CharField(max_length = 12)
class AuthorDetail(BaseModel):
    mobile = models.CharField
    author = models.OneToOneField(
# 关联的表
        to = 'Author',
# 表之间连接：False
        db_constraint = False,
# 删除时，级联删除,在外键或者一对一中，多对多没有这个属性
        on_delete = models.CASCADE,
# 反向查找时：通过Author对象的.detail可以找到AuthorDetail
        related_name = 'detail'
)

author = models.Author.objects.first()
print(author.name)
print(author.detail.mobile)

序列化-----之自定义深度

class
    field = ('name','age')  # 展示的字段
    exclude = ('id','create_time')  # 不展示的字段
    depth = 1 # 会自动把深度为一的连接拉出来：自动深度，可控制性不强

1. 深度发生在表连接的时候，所以在类中定义一个函数，该函数通过外键属性访问其他表，并返回值，在序列化的时候，field不仅可以接收字段，还可以接受函数。最好

class XXX(models.Model):
    name = models.CharField(max_length = 12)
    xxx = models.ForenginKey(to = 'YYY',on_delete = models.CASCADE)
    def special(self):
        return self.xxx.yyy
class YYY(models.Model):
    name = models.CharField(max_length = 14)
    yyy= models.CharField(max_length = 16)

# 上面是类
# 序列化中
from .models import XXX
class XXXSerializer(serializers.ModelSerializer):
    class Meta:
        model = XXX
        field = ('name','special')   # 很强大，接收函数获取返回值来实现深度

在标准一点就是在special函数上面使用property装饰器，告诉你这就是一个属性，他会返回一个值
2. 还可以通过使用SerializerMethodField()来获取，但是就必须将该字段一直插着，可插拔行不好，所以不常用
3. 使用已有的序列化类声明字段，不好说明直接代码，虽然这个方法也是必须一直插着，但是比方法2要友好。

# 还是上面的XXX和YYY
# 在序列化的时候，为YYY先序列化，在为XXX序列化，
class XXXSerializer(serializers.ModelSerializer):
    class Meta:
        model = XXX
        field = ('name',)   # 很强大，接收函数获取返回值来实现深度
class XXXSerializer(serializers.ModelSerializer):
    class Meta:
        xx = XXXSerializer()   # 这xx字段就可以自动的显示XXXSerializer的内容了
                    #  xx在XXX模型类中是有这个属性的。
        model = XXX
        field = ('name','xx')   # 很强大，接收函数获取返回值来实现深度

反序列化的系统校验规则

除了全局钩子和局部钩子还有系统自带的校验规则，钩子写在元类Meta外边。

extra_kwagrs = {
    '字段名字':{
          '校验规则':True,
          'required':True,
          'min_length':10,
          'error_messages':{
              '校验规则':'错误信息',
               'required':'这个字段是必须的',
                'min_length':'太短了'
           }
    }
}

关于接收的参数 ---- 重要 ------- 重要

增加数据时，一般外键接收的数据是id，例如Book类中有name属性，author多对多作者表，publish是出版社表的外键。前端增加的数据格式为

{
    'name':"红楼梦",
    'author':[1,2],
    'publish':1
}
或者
[
    {
        'name':"红楼梦",
        'author':[1,2],
        'publish':1
    },
    {
        'name':"金瓶梅",
        'author':[1,3],
        'publish':2
    }
]

现在有一个逻辑，同一个出版社的不能出现两本同样的书：现将书查出来，再查书对应的出版社，如果跟增加的出版社相同，该书不能出版。

    def validate(self, attrs):
        book = models.Book.objects.filter(name=attrs.get('name'))
        if book is not None:
            for b in book:
                if b.publish == attrs.get('publish'):
                    raise ValidationError({'重复':'该出版社已经有了'})
        return attrs

其中打印了b.publish和attrs.get('publish')的值，其中b.publish是Publish类对象，attrs.get('publish')得到的不是id，而是Publish对象。

单增，群增POST

• 单增：前台的数据返回的是一个字典。
• 群增：前台数据传来的是一个字典的列表。
• 字典就是单增，many=False,列表就是群增，many=True

def post(self,request,*args,**kwargs):
    request_data = request.data
    if isinstance(request_data,dict):
        many = False
    elif isinstance(qequest_data,list):
        many = True
    else:
        return Response('数据错误')
    bookser  = BookSerializer(data = request_data,many=many)
    #  如果校验失败直接抛出异常
    bookser.is_valid = (raise_exception=True)
    book_ret = bookser.save()
    return Response({
        'ret':BookSerializer(book_ret,many=many).data
    })
  

单删，群删DELETE

• 前台的数据，单删：通过url的参数来删除~/books/1。
  群删：通过body里面参数{'pks':[1,2,3]}
• 把单删的url放前面，然后在视图中判断，如果pk存在，就把pk作为一个集合，如果pk不存在，就从request.data中取出数据pks。将数据更新。
• 删除没有添加数据，所以不用经过序列化，并且也不是真正的删除。

def delete(self,request,*args,**kwargs):
    pk = kwargs.get('pk')
    if pk:
        pks = [pk]
    else:
        pks = request.data.get('pks')
    models.Book.objects.filter(pk__in=pks).update(is_delete=True)

整体单改PUT

核心跟POST一样，只不过需将要更新的数据放在instance里面，更新的数据放到data里面

• 单改要在url中传入pk，要在body中传入单个对象所有的必须数据
• 和增加一样，也要调用ser的save方法，只不过，save方法在里面有判断，如果instance有值就执行update操作，没有值就执行create操作，所以为instance传值，传old_obj

def put(self,request,*args,**kwargs):
    request_data  = request.data
    pk = kwargs.get('pk')

    old_obj = Book.objects.filter(pk=pk).first()

    book_ser = BookSerializer(instance = old_obj,data = request_data)
    book_ser.is_valid(raise_exception = True)
    # 使用if判断是一样的，只不过这样简单
    book_ret = book_ser.save()
    return Response({
    'ret':BookSerializer(instance=book_ret)
    })

局部单改PATCH

局部修改提供的参数必然是不全的，所以无法通过is_valid数据校验，序列化中时有一个partial参数，指定为局部修改，可以理解为不填的数据自动使用旧数据，填的数据使用校验规则进行校验
book_ser = BookSerializer(instance=old_obj,data = request_data,partial=True)

book_ser = BookSerializer(instance=old_obj,data = request_data,partial=True)
# 其他和整体单改相同

整体群改PUT

整体的单改属于整体的群改，所以可以像delete那样，都整合到一起
永远不要在for循环中对列表长度做操作，十秒之前的水不是现在的水

局部群改PATCH

视图和序列化类是可以进行数据交互的，通过context = {'request',request}传参数，再然后序列化类中可以使用self.context得到这个字典。

拿到pks，将已删除的pk的request_data删除，留下的就只有pks = [],request_datas = [request_data,]。
定义一个继承自ListModelSerializer,重写里面的update()方法，和create方法差不多，可以根据他的格式搬过去，update方法接收两个参数(instance,valided_data),正好这两个数据都坐在里面。