木炭

GOOD！ 看来是时候将 csredis 换成 FreeRedis 了

> 这个问题已知3年了，没有很好的办法解决，因为仓储内部无法判断引用类型来决定是否更新。 方法一：将对象转JSON后比较字符串 方法二：更新时增加一个是否强制更新 JsonMap 字段的参数 方式一有点点性能损耗，我觉得非高性能场景可能可以忽略 方法二则不能自动更新字段，需要人工设置，但是设计人员自己最清楚，自己的 JsonMap 是否需要更新，所以这个方法可能更好

我觉得很有可能是网络问题。 我尝试过内网不同机器装同样的库，A 机器工作了几个月很正常，但是某天无故操作很慢，慢到打开一个连接都需要十多秒，就算我重装库，问题依旧。于是通过 B 机器安装，一切正常。差不多又过了几个月，无意中又发现 A 机器又完全正常了。 不能说阿里系统存在问题，所以我觉得问题更多再网络连接上

> 暂不支持转发过程增加前缀路径，这功能后期应该会增加 建议转发的时候将 Server 的 Host 也转发过去

nocobase 在创建子应用其实相当于复制了一份数据到新库中，两应用是独立的。比如用户不是公用的，而是单独隔离的。所以权限也同时也创建了一份，其实原因是这些基础数据没有共享 插件中应用数据共享支持 pgsql，我没有测试过，不知道这些基础数据是否可以共享。 其实我觉得只要 nocobase 用租户的模式来处理多应用应该很好解决，比如说：基础数据用户权限是通用的表，而如果增加应用可以通过不同的数据表前缀来区分；又或者通过租户字段来区分。如果非要使用不同库来区分的，权限数据只存在主库就可以了

你这个是在 AOP 之前的处理，我的想法是如果我通过 AOP 来审计某些数据的时候，对于非法内容可以统一处理了。因为毕竟不是每隔业务处理的时候都会及时对数据进行清洗。 如果我在AOP 审计数据的时候发现问题，就可以及时记录并纠正。

触发异常只会导致整个数据库操作失效，而无法做到某个字段的审计。 可能我这个想法比较小众。 我的目的是对入库的数据进行一次审计，如果此数据某个字段存在异常或者需要人工审核，那么我禁止此字段更新，记录到后台，但是原数据其他字段更新不中断。 后期管理人员对此字段的数据进行检查，如果确实存在问题，那么直接拒绝操作，不对已入库的数据进行修改。如果检查没有问题，审核通过，则自动更新原始数据中对应字段的值。 目前审核流程是基于上位模块的专门接口操作，所以现在新建项目都需要通过此模块来处理。 但是因为所有数据都必须入库，同时 freesql 本身 aop 可以拦截，所以想通过数据库入库 aop 来拦截处理。这应该是最简单最高效的方法了。 因为既然 freesql 存在 AuditValue ，那么是不是可以让其值取消更新。 比如在 AuditValue 增加一个 cancel 属性，如果为 true，那么入库前就自动忽略此字段即可。