MyBatis-Plus 3.5.8版本逻辑删除与乐观锁冲突问题解析

问题背景

在MyBatis-Plus框架的3.5.8版本中，开发者发现了一个关于逻辑删除与乐观锁机制冲突的问题。具体表现为：当使用BaseMapper的deleteBatchIds方法执行逻辑删除操作时，会自动触发updateFill方法，这与3.5.5版本的行为不同。

问题现象

在3.5.5版本中，执行deleteBatchIds方法进行逻辑删除时，不会触发自动填充字段的updateFill方法。而在3.5.8版本中，同样的操作会触发updateFill方法，这导致了一些依赖乐观锁版本校验的业务逻辑出现问题。

技术分析

逻辑删除机制

MyBatis-Plus提供了逻辑删除功能，它通过在表中设置一个标志位（如deleted字段）来标记记录是否被删除，而不是真正从数据库中物理删除记录。这种方式可以保留历史数据，便于数据恢复和审计。

乐观锁实现

乐观锁通常通过版本号机制实现，在数据更新时会检查版本号是否匹配。在MyBatis-Plus中，可以通过@Version注解标记版本号字段，并在更新时自动进行版本校验。

版本变更影响

3.5.8版本对逻辑删除的实现进行了调整，使得deleteBatchIds方法会触发updateFill方法。这一变更导致以下问题：

1. 在updateFill方法中获取版本号时，由于逻辑删除操作可能没有传入版本号，导致获取到的值为null
2. 如果业务代码中有对版本号的非空校验，就会抛出异常

解决方案

MyBatis-Plus在3.5.8版本中已经将deleteBatchIds方法标记为过时(deprecated)，并提供了新的deleteByIds方法作为替代。新方法提供了更灵活的配置选项：

// 使用deleteByIds方法并设置useFill参数
deleteByIds(ids, useFill);

通过设置useFill参数，可以控制是否在逻辑删除操作中触发自动填充功能，从而避免与乐观锁机制的冲突。

最佳实践建议

1. 对于新项目，建议直接使用deleteByIds方法替代过时的deleteBatchIds方法
2. 在需要进行逻辑删除且涉及乐观锁的场景中，合理设置useFill参数
3. 在updateFill方法中增加对逻辑删除操作的判断，避免不必要的版本号校验
4. 升级到最新版本时，注意检查所有使用过时方法的地方，并进行相应替换

总结

MyBatis-Plus在版本迭代过程中不断优化功能实现，开发者需要关注版本变更日志和API文档的变化。对于逻辑删除与乐观锁这种常见的业务场景，理解框架底层实现机制有助于更好地解决实际开发中遇到的问题。通过合理使用新版本提供的API和配置选项，可以构建更加健壮的数据访问层。