shenjl
shenjl
哈哈，我也觉得是。毕竟国外的是羊驼，国内叫华驼没毛病
在假删除的时候，不应该是 当 method == DELETE 时, 获取access记录并赋值给 accessFakeDeleteMap变量吗？为什么赋值是反过来了的？ Map accessFakeDeleteMap = method == DELETE ? AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()) : null;
我知道项目启动的时候, 会初始化Access表的假删除字段 配置。没有问题。 可能我描述问题不是很清晰吧，导致你理解错我的意思了。现在这里的代码逻辑是 Map accessFakeDeleteMap = method == DELETE ? null : AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()); 意思是非DELETE的方法才取这个access记录吗？DELETE请求时，则为null ？ 而不是应该这样吗: Map accessFakeDeleteMap = method == DELETE ? AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()) : null; 可能我理解不对，求教。
好的，谢谢了。理解了第一种删除（够用了），没想到还可以处理 delete 子查询。
> 改成false就可以了 确实这里改成false可以了。明白了，这里是添加过滤条件的。
这里要加判空处理，否则，项目启动时会报空指针错误。
还有个问题，就是当不传条件时，会把已删除（ is_del=1 ）的数据也查询出来。
断点调试了，在[AbstractSQLConfig.newSQLConfig](https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L4931) 的 request.isEmpty() 时，会直接返回了config对象。所以要加个过滤条件或者排序，使request不为Empty，才会加上is_del = 0条件。 https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L4931