@n329291362
@omri
还真有这个写法, 不过官方文档只介绍了 QuerySet filter, 没想到 manager, 不过跟踪实例字段变化已经有更好的实现思路了
manager 这部分也只是在 ORM 这边, 要和 request 有关系还是要在每个视图里面写逻辑

@sivacohan
我这里其实是需要把 2 个部分关联起来的, 一边是 ORM 操作, 另一边是视图, 大部分情况下其实可以关联起来, 不过这里要做一个全局的, 也不要每个接口单独配置, 每个视图都要写逻辑的这种
目前看来使用 threadlocals 应该可以

@freakxx
恩,是拆成 2 个部分, 不过现在要把 2 个部分关联起来, 也就是一个 request 引起的多个记录关联起来, 这些都要和用户关联

跟踪一个实例的 field change 的话我是直接改__init__和__setattr__方法添加一个属性就可以实现, 并且只记录了更改的 field. 没有变的 field 不会记录, 在实例更改保存的时候使用了信号来保存更改之前之后的值, 直接 copy 整个实例 emmm 貌似太伤了

@ohhe 这个做的比较好了
这个必须在每个模型中定义一个 history, 不能抽象类继承, 并且一个每个模型都会创建一张记录表
与用户关联的话, 依赖 django 的中间件, 如果使用 rest_framework 自定义用户验证的话, 得不到用户的, 所以必须每次更改的时候传入 user

@omri
单独记录 request 或者单独记录一条数据的操作记录不难的，就是 2 个关联起来。。。
然后单独记录一条数据的操作记录其实已经有第三方现成的插件了，我自己的话是用的信号机制实现的，没有深入到涉及 SQL
真的有重写 manager filter 方法嘛，是啥意思我完全没懂，没有搜到文档哎😄

其实就是感觉 django 缺个像 flask 的 4 个全局对象, flask 的全局 request 在很多地方都可以用

@omri 让前端传改之前的数据也不太好, 本来改之前的数据数据库中都有, 而且前端传回来的数据也不完全可信, 如果有逻辑要依赖这个之前的数据的话更不好了

@omri 应该都包括吧, 用户的一个操作一般对应了一个请求嘛, 但是不同情况下同一个 URL 请求到后台具体会引起那些表的那些记录的增删改查的那个一个操作都是不确定的, 所以记录了 request 的 url, 还记录增删改查个中的哪一个, 如果是改的话得记录改前改后的值分别是啥, 并且这些记录都和这个用户关联起来

这个操作记录是要全局有效的, 每个应用都会用到, 并且新增应用(也就是新的 model 的增删改查)的时候, 不再关心也不需要再写操作记录方面的任何逻辑, 就像这个操作记录不存在一样

request 大部分时候是能够拿到的, 但是为了上面的要求, 在操作记录的实现逻辑代码里面不能同时得到 request 和这个 request 到底引起那些模型的那些实例的那些字段的改变

全局的 dict 是啥, python 的全局可用嘛, 还是借助外部比如 redis 啥的

@n329291362 emmm Manager 有 filter,我不知道...每个地方都手动写代码也太不好了, 设计的目地就是一个全局的用户操作记录, 而不是某几个应用

@n329291362 恩,已经了解到了全局对象