资讯专栏INFORMATION COLUMN

Django ORM层日志的两种实现方式

CKJOKER / 2729人阅读

摘要:最近开发一个内部的记录系统其中有一个需求要求将所有数据库操作记录下来为此想了一些方案记录一下思路演化这个需求出来的一瞬间我就否定了在业务逻辑层保存操作记录的方案我认为这样耦合度比较高成本也太高代码也会大量重复的操作中删除操作会调用的方法增改

最近开发一个内部的记录系统,其中有一个需求要求将所有数据库操作记录下来,为此想了一些方案.记录一下.

思路演化

这个需求出来的一瞬间我就否定了在业务逻辑层保存操作记录的方案,我认为这样耦合度比较高,成本也太高. 代码也会大量重复.
Django的ORM操作中,删除操作会调用models.Modeldelete方法,增改会调用save方法,修改这些方法能够覆盖除了查询以外的所有ORM操作(查询暂时跳过),修改savedelete的方法无外乎就是类继承,装饰器.

我也考虑了使用signal系统,但是这样依然要在业务逻辑层处理发送信号的问题,感觉更复杂一些(比如对照修改前后的数据不如直接在Model中操作方便,Model的save方法在存盘之前,self是待存数据,根据self.pk从db中取出数据是旧数据方便对比.如果要在signal中拿到两份数据比较麻烦,可能需要在业务层做更多的斟酌).

继承

我首先尝试了类继承的方法

class TopSecret(models.Model):

    class Meta:
        db_table = "绝密文件"

    name = models.CharField(max_length=32)
    content = models.TextField()

这是原始的model,我改写成了如下

class Logger(models.Model):

    def save(self, *args, **kwargs):
        print("Do some log")
        super(Logger, self).save(*args, **kwargs)


class TopSecret(Logger):

    class Meta:
        db_table = "绝密文件"

    name = models.CharField(max_length=32)
    content = models.TextField()

我觉得这样应该可以的.然而在调用save()方法时出现错误OperationalError: no such table: logged_logger,可以看出,我在原始model定义的Meta信息失效了,框架转而在Logger类中寻找Meta,未找到的情况下使用了框架的默认值.
我尝试将super(Logger, self).save(*args, **kwargs)改成super(self.__class__, self).save(*args, **kwargs),这样super又成了调用TopSecret父类Logger的save(),如此反复形成了循环调用报错.
我仔细想了一下,Model类寻找Meta的逻辑是肯定不去修改的,修改这个显得不划算,也违反了不随便改框架的基本原则,当时在此我转向了装饰器方法,而放弃了类继承.
今天我写这篇文章的时候隐约想起一件事情,Model好像有一个abstract的属性,果然如此.定义这个Meta信息之后,框架会认为这是一个抽象类,而不是数据模型,完美解决了问题.

class Logger(models.Model):

    class Meta:
        abstract = True

    def save(self, *args, **kwargs):
        print("Do some log")
        super(Logger, self).save(*args, **kwargs)


class TopSecret(Logger):

    class Meta:
        db_table = "绝密文件"

    name = models.CharField(max_length=32)
    content = models.TextField()
In [1]: from logged.models import TopSecret

In [2]: obj = TopSecret(name="123",content="测试内容")

In [3]: obj.save()
Do some log

In [4]:

在想起abstract之前我还想过其他的方案,比如多带带增加log类.这样可以避免在Model父类和子类之间增加一层,解决了Meta信息的问题.

class Logger(object):

    def save(self, *args, **kwargs):
        print("Do some log")
        models.Model.save(self, *args, **kwargs)


class TopSecret(Logger, models.Model):

    class Meta:
        db_table = "绝密文件"

    name = models.CharField(max_length=32)
    content = models.TextField()

这样做有好处也有坏处,好处是Logger不再继承Model,算是解耦合增加了代码的可读性,坏处是我看Logger那里调用save方法的方式比较别扭,将实例方法当做静态方法调用手动传入实例有一种很违和的感觉,不过总算是能工作了.

装饰器

装饰器是当时类继承没有成功,我走的另一条路.

首先因为我们的装饰器不可能装到框架代码里去,只能在我们定义的Model模型上使用类装饰器.当时我的实现是使用django自带的method_decorator.这个函数可以将函数装饰器变成方法装饰器,装饰到一个类的方法上,比较常见的用法是为dispatch方法去除csrf保护.
但是使用这个方法会有一个问题,那就是写一个函数装饰器本身是不会取到类的实例本身的.还需要为save方法传入类的实例本身才能取到类数据进行日志操作,不行,不够优雅.

怎么办?只能直接写类装饰器了.

之前没写过类装饰器,其实类装饰器和普通函数装饰器一样,思路和继承的写法也是一样的.

def cbd_logger(obj):
    if hasattr(obj, "save"):
        save = obj.save 
        def _save(self, *args, **kwargs):
            print "do some log %s" % self.name
            return save(self, *args, **kwargs)
        setattr(obj, "save", _save)
    return obj


@cbd_logger
class TopSecret(models.Model):

    class Meta:
        db_table = "绝密文件"

    name = models.CharField(max_length=32)
    content = models.TextField()
值得注意的是,_save中不能直接return obj.save(self,*args,**kwargs),这么做会导致运行时调用当前实例的save方法,也就是_save本身,搞成无限递归  
我们分别打印一下cbd_logger下这些方法的id看一下
>>>obj.save()
save 90220624
obj.save 106285376
self.save 106285376
在装饰后的save方法中,obj.save的地址和self.save的地址是一样的,这个save已经被装饰器修改过了.
和下面这个闭包的原理差不多.
>>>fs = [lambda i:i*2 for i in range(3)]
>>>for f in fs:
...    print(f(1))
2
2
2
总结

类的继承方法和装饰器方法实际上都在做同一件事,就是在框架本身的savedelete方法外层增加日志操作.但是需求还没有实现,我们保存日志的时候,不只要知道数据变动,还要知道这些操作是谁做的,如何优雅的将这些信息传递给负责记录的代码?
目前我们选择的是在操作Model时,约定不使用objects,只使用TopSecret(name="",content="").save(request)这种方法,将request传递给save,再由之前实现的logger从request取出必要的信息进行记录,比如IP,User,甚至UA等等.这么做业务层需要多传一个参数,还是有了感知,但是也是没办法的事.对现有代码的改动也是我知道的办法中最小的.
这套下来感觉django文档中的给出的信息很充分,实现这个需求并不难.一开始出现的问题还是因为对文档印象不够深,没有第一时间解决问题.

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/41766.html

相关文章

  • Django ORM日志两种实现方式

    摘要:最近开发一个内部的记录系统其中有一个需求要求将所有数据库操作记录下来为此想了一些方案记录一下思路演化这个需求出来的一瞬间我就否定了在业务逻辑层保存操作记录的方案我认为这样耦合度比较高成本也太高代码也会大量重复的操作中删除操作会调用的方法增改 最近开发一个内部的记录系统,其中有一个需求要求将所有数据库操作记录下来,为此想了一些方案.记录一下. 思路演化 这个需求出来的一瞬间我就否定了在业...

    wudengzan 评论0 收藏0
  • 通过demo学习OpenStack开发所需的基础知识 -- 数据库(1)

    摘要:另外,项目在单元测试中使用的是的内存数据库,这样开发者运行单元测试的时候不需要安装和配置复杂的数据库,只要安装好就可以了。而且,数据库是保存在内存中的,会提高单元测试的速度。是实现层的基础。项目一般会使用数据库来运行单元测试。 OpenStack中的关系型数据库应用 OpenStack中的数据库应用主要是关系型数据库,主要使用的是MySQL数据库。当然也有一些NoSQL的应用,比如Ce...

    warnerwu 评论0 收藏0
  • Django Model View Template 之间的简单交互 (二)

    摘要:当然还有其他高级的使用,日后再说完整的用户名邮箱联系地址留言信息用户留言信息使用之前已经定义好了数据模型的字段元数据方法等。 前言 接续前文,上一篇文章主要涉及了 Django 项目的基础配置等,这篇主要涉及数据库相关的 ORM ,也就是 Django 中的 Model 的使用,MVT 三层之间的交互 教程基本都是东拼西凑的,防止有些东西表述不准确,因为我之前写 JavaScript ...

    Coding01 评论0 收藏0
  • Django ORM

    摘要:对象关系映射,简称模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。在业务逻辑层和数据库层之间充当了桥梁的作用。每个字段被指定为一个类属性,每个属性映射到一个数据库列。字符类型,必须提供参数,表示字符长度。 对象关系映射(Object Relational Mapping,简称ORM)模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是...

    BlackHole1 评论0 收藏0
  • Django-01、初识Django和搭建Django helloworld

    摘要:并于年月在许可证下发布。控制器是将模型和视图隔离,并成为二者之间的联系纽带。该层处理与表现相关的决定如何在页面或其他类型文档中进行显示。会话用户登录与权限检查,快速开发用户会话功能。 1.介绍Django 1.1 Django的来源 Django是一个开放源代码的Web应用框架,由Python写成。采用了MVC的框架模式,即模型M,视图V和控制器C。它最初是被开发来用于管理劳伦斯出版集...

    lewif 评论0 收藏0

发表评论

0条评论

CKJOKER

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<