Repository navigation
假删除时，报空指针错[Bug] #602
Description
APIJSON Version/APIJSON 版本号
6.2.0
Database Type & Version/数据库类型及版本号
Mysql 8
Environment/环境信息
- JDK/基础库: 1.8
- OS/系统: MacOSAPIAuto 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 设置为1Any 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
Activity
shenjler commentedon Aug 25, 2023
cloudAndMonkey commentedon Aug 25, 2023
shenjler commentedon Aug 25, 2023
在假删除的时候，不应该是 当 method == DELETE 时, 获取access记录并赋值给 accessFakeDeleteMap变量吗？为什么赋值是反过来了的？
Map<String, Object> accessFakeDeleteMap = method == DELETE
? AbstractVerifier.ACCESS_FAKE_DELETE_MAP.get(config.getTable()) : null;
cloudAndMonkey commentedon Aug 25, 2023
项目启动的时候, 会初始化Access表的假删除字段.
代码执行阶段都是读取配置
shenjler commentedon Aug 25, 2023
我知道项目启动的时候, 会初始化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 commentedon Aug 25, 2023
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 commentedon Aug 25, 2023
好的，谢谢了。理解了第一种删除（够用了），没想到还可以处理 delete 子查询。
shenjler commentedon Aug 25, 2023
确实这里改成false可以了。明白了，这里是添加过滤条件的。
Update AbstractSQLConfig.java
shenjler commentedon Aug 28, 2023
这里要加判空处理，否则，项目启动时会报空指针错误。
shenjler commentedon Aug 28, 2023
还有个问题，就是当不传条件时，会把已删除（ is_del=1 ）的数据也查询出来。
TommyLemon commentedon Aug 28, 2023
断点调试下，只要假删除配置正确，除了 POST 外，其它都会在 AbstractSQLConfig.getWhereString 时加上条件 is_del = 0 或 is_del != 1 才对
shenjler commentedon Aug 29, 2023
断点调试了，在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 commentedon Aug 29, 2023
@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 commentedon Aug 31, 2023
@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 commentedon Dec 2, 2023
我看了 apijson-ruoyi 他是加了排序条件，如果不加也是不生效的