oup2.0优化中,对乐观锁进行了重点关注,在优化中,发现乐观锁注解存在,但在部分功能中没有生效。
ps:数据库设计是门艺术,体验实践,结合设计思想。一份好的存储设计,支持横向、垂直双向扩展,兼顾业务、技术升级,同时支持不同类型存储的交叉夸张。
定位
oup中实现了前端模块化,通过java编码+前端模板+js互动,降低后端编码人员的前端编码能力,同时模板化的设计,提高了模板的高复用和标准化,js分离操作,实现逻辑和样式的分离,有点走偏。由于update操作从oup-console到oup-service穿透较多,故从前端输入、数据库sql二端入手,进行定位:
1、通过sql判断,确认update操作时,无@Version字段引入。
2、前端输入判断,确认无@Version字段输入。
基于第1点,再次深化到组件fastmybatis的核心源代码。确认在BaseServicempl.java中使用的updateByQuery的sql模板中,没有乐观锁的条件组装,故判断该方法不支持乐观锁。(回顾以往乐观锁定义:在全对象更新时,版本字段自动增加,乐观锁默认生效。对于指定sql由于版本字段无无法实现自动追加,需要手工拼装sql条件。)确认调用的updateByQuery方法错误。
解决
调整为updateIgnoreNull后,再次测试,乐观锁生效,该操作的前提是,数据库对象需要先查询后操作,若实现前端展示,需要传递到前端,在请求内包含。
ps:观fastmybatis源码底层,代码不多,设计思路也比较清晰,但解决问题的方式比较好,大大降低了编码量,并结合底层,保留了其原始扩展能力。