假删除时，报空指针错[Bug]

[shenjler]

APIJSON Version/APIJSON 版本号

6.2.0

Database Type & Version/数据库类型及版本号

Mysql 8

Environment/环境信息

- JDK/基础库: 1.8
- OS/系统: MacOS

APIAuto Screenshots/APIAuto 请求与结果完整截屏

无法粘贴图片

Current Behavior/问题描述

重现步骤：
在数据库Aceess配置表增加了3个字段：deletedKey、deletedValue、notDeletedValue，
在Aceess表的Customer行记录（对应customer表）,插入值 deletedKey = is_del, deletedValue = 1, notDeletedValue=0。（这里举例使用customer表）
在customer表有字段：is_del，默认值0
DemoSQLConfig 重写了 isFakeDelete方法 返回true

调用接口 POST: /delete
参数：{"Customer":{"id":15}}

Expected Behavior/期望结果

正常实现假删除，把 字段is_del 设置为1

Any additional comments?/其它补充说明？

这里的 判断 method == DELETE 并赋值为null 是否有问题？导致空指针问题。
Map<String, Object> accessFakeDeleteMap = method == DELETE
							? null : AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable());

https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L5240

[shenjler]

[cloudAndMonkey]

改成false就可以了

[shenjler]

在假删除的时候，不应该是 当 method == DELETE 时, 获取access记录并赋值给 accessFakeDeleteMap变量吗？为什么赋值是反过来了的？ Map<String, Object> accessFakeDeleteMap = method == DELETE ? AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()) : null;

[cloudAndMonkey]

项目启动的时候, 会初始化Access表的假删除字段. 代码执行阶段都是读取配置

[shenjler]

我知道项目启动的时候, 会初始化Access表的假删除字段 配置。没有问题。 可能我描述问题不是很清晰吧，导致你理解错我的意思了。现在这里的代码逻辑是 Map<String, Object> accessFakeDeleteMap = method == DELETE ? null : AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable());

意思是非DELETE的方法才取这个access记录吗？DELETE请求时，则为null ？ 而不是应该这样吗:

Map<String, Object> accessFakeDeleteMap = method == DELETE ? AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()) : null;

可能我理解不对，求教。

[cloudAndMonkey]

https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L5386-L5407 这里是处理method = delete, 将delete 修改为update

https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L5240 这里是处理 delete 子查询 (同一张表,好像 TommyLemon后面还加了其他条件, 我好久没看了,有点忘记了,哈哈 ) { "sql@": { "with": true, "from": "Sys_user_role", "Sys_user_role": { "@column": "user_id", "role_id{}": ["023e1880-c0d4-4e7c-ae6c-7703199c2daf"] } }, "Sys_user:aa": { "id{}@": "sql" }, "explan": true }

[shenjler]

好的，谢谢了。理解了第一种删除（够用了），没想到还可以处理 delete 子查询。

[shenjler]

改成false就可以了

确实这里改成false可以了。明白了，这里是添加过滤条件的。

[shenjler]

这里要加判空处理，否则，项目启动时会报空指针错误。

[shenjler]

还有个问题，就是当不传条件时，会把已删除（ is_del=1 ）的数据也查询出来。

[TommyLemon]

断点调试下，只要假删除配置正确，除了 POST 外，其它都会在 AbstractSQLConfig.getWhereString 时加上条件 is_del = 0 或 is_del != 1 才对

[shenjler]

断点调试了，在AbstractSQLConfig.newSQLConfig 的 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

[cloudAndMonkey]

@shenjler 除了 https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L5246 需要改成false 不需要改源码, 你去看 https://gitee.com/yxiedd/apijson-ruoyi, 可以在线测试

[TommyLemon]

断点调试了，在AbstractSQLConfig.newSQLConfig 的 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

@shenjler 看起来应该在 if (request.isEmpty()) 之前判断 ACCESS_FAKE_DELETE_MAP 是否包含了当前表的假删除配置，如果有，就不 reutrn config： if (request.isEmpty() && (accessFakeDeleteMap == null || accessFakeDeleteMap.isEmpty()))

https://github.pccwhq.com/Tencent/APIJSON/blob/c8c3b92ce3bfec5922eab2919588039ddbc99709/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java#L5238-L5241

可以用 apijson-ruoyi 先试试，不行的话改下源码试试

[csx-bill]

我看了 apijson-ruoyi 他是加了排序条件，如果不加也是不生效的