最近开发一个内部的记录系统,其中有一个需求要求将所有数据库操作记录下来,为此想了一些方案.记录一下.
思路演化
这个需求出来的一瞬间我就否定了在业务逻辑层保存操作记录的方案,我认为这样耦合度比较高,成本也太高. 代码也会大量重复.
Django的ORM操作中,删除操作会调用models.Model的delete方法,增改会调用save方法,修改这些方法能够覆盖除了查询以外的所有ORM操作(查询暂时跳过),修改save和delete的方法无外乎就是类继承,装饰器.
我也考虑了使用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
总结
类的继承方法和装饰器方法实际上都在做同一件事,就是在框架本身的save和delete方法外层增加日志操作.但是需求还没有实现,我们保存日志的时候,不只要知道数据变动,还要知道这些操作是谁做的,如何优雅的将这些信息传递给负责记录的代码?
目前我们选择的是在操作Model时,约定不使用objects,只使用TopSecret(name="",content="").save(request)这种方法,将request传递给save,再由之前实现的logger从request取出必要的信息进行记录,比如IP,User,甚至UA等等.这么做业务层需要多传一个参数,还是有了感知,但是也是没办法的事.对现有代码的改动也是我知道的办法中最小的.
这套下来感觉django文档中的给出的信息很充分,实现这个需求并不难.一开始出现的问题还是因为对文档印象不够深,没有第一时间解决问题.
