4.1.5 模型之持久层配置

一、批量操作

批量操作包括批量创建与批量更新。批量操作的提交类型系统默认值为batchCommit。

批量提交类型:

  • useAffectRows,循环单次单条脚本提交,返回实际影响行数
  • useAndJudgeAffectRows,循环单次单条脚本提交,返回实际影响行数,若实际影响行数与输入不一致,抛出异常
  • collectionCommit,将多个单条更新脚本拼接成一个脚本提交,不能返回实际影响行数
  • batchCommit,使用单条更新脚本批量提交,不能返回实际影响行数。

全局配置

pamirs:
    mapper:
    batch: batchCommit

图4-1-5-1 全局配置

运行时配置

非乐观锁模型系统默认采用batchCommit提交更新操作;乐观锁模型默认采用useAndJudgeAffectRows提交更新操作。也可以使用以下方式在运行时改变批量提交方式。

Spider.getDefaultExtension(BatchApi.class).run(() -> {
    更新逻辑
}, 批量提交类型枚举);

图4-1-5-2 运行时配置

运行时校正

如果模型配置了数据库自增主键,而批量新增的批量提交类型为batchCommit,则系统将批量提交类型变更为collectionCommit(如果使用batchCommit,则需要单条提交以获得正确的主键返回值,性能有所损失)。

如果模型配置了乐观锁,而批量更新的批量提交类型为collectionCommit或者batchCommit,则系统将批量提交类型变更为useAndJudgeAffectRows。也可以失效乐观锁,让系统不做批量提交类型变更处理。

二、乐观锁(举例)

在一些会碰到并发修改的数据,往往需要进行并发控制,一般数据库层面有两种一种是悲观锁、一种是乐观锁。oinone对乐观锁进行了良好支持

定义方式

乐观锁的两种定义方式:

  • 通过快捷继承VersionModel,构建带有乐观锁,唯一编码code且主键为id的模型。

  • 可以在字段上使用@Field.Version注解来标识该模型更新数据时使用乐观锁

如果更新的实际影响行数与入参数量不一致,则会抛出异常,错误码为10150024。如果是批量更新数据,为了返回准确的实际影响行数,批量更新由批量提交改为循环单条数据提交更新,性能有所损失。

失效乐观锁

一个模型在某些场景下需要使用乐观锁来更新数据,而另一些场景不需要使用乐观锁来更新数据,则可以使用以下方式在一些场景下失效乐观锁。更多元位指令用法详见4.1.9【函数之元位指令】一文。

PamirsSession.directive().disableOptimisticLocker();
try{
    更新逻辑
} finally {
    PamirsSession.directive().enableOptimisticLocker();
}

图4-1-5-3 失效乐观锁

不抛乐观锁异常

将批量提交类型设置为useAffectRows即可,这样可改由外层逻辑对返回的实际影响行数进行自主判断。

Spider.getDefaultExtension(BatchApi.class).run(() -> {
    更新逻辑,返回实际影响行数
}, BatchCommitTypeEnum.useAffectRows);

图4-1-5-4 将批量提交类型设置为useAffectRows

构建第一个VersionModel

Step1 新建PetItemInventroy模型,继承快捷模型VersionModel

package pro.shushi.pamirs.demo.api.model;

import pro.shushi.pamirs.meta.annotation.Field;
import pro.shushi.pamirs.meta.annotation.Model;
import pro.shushi.pamirs.meta.base.common.VersionModel;

import java.math.BigDecimal;

@Model.model(PetItemInventroy.MODEL_MODEL)
@Model(displayName = "宠物商品库存",summary="宠物商品库存",labelFields = {"itemName"})
public class PetItemInventroy extends VersionModel {
    public static final String MODEL_MODEL="demo.PetItemInventroy";

    @Field(displayName = "商品名称")
    private String itemName;

    @Field(displayName = "库存数量")
    private BigDecimal quantity;

}

图4-1-5-5 新建PetItemInventroy模型

Step2 修改DemoMenu,增加访问入口

@UxMenu("商品库存")@UxRoute(PetItemInventroy.MODEL_MODEL) class PetItemInventroyMenu{}

图4-1-5-6 修改DemoMenu

Step3 重启看效果

体验一:页面上新增、修改数据库字段中的opt_version会自动加一

image.png

图4-1-5-7 示例效果一

image.png

图4-1-5-8 示例效果二

image.png

图4-1-5-9 示例效果三

image.png

图4-1-5-10 示例效果四

体验二:同时打两个页面,依次点击,您会发现一个改成功,一个没有改成功。但页面都没有报错,只是update返回影响行数一个为1,另一个为0而已。

image.png

图4-1-5-11 编辑宠物商品库存

image.png

图4-1-5-12 宠物商品库存列表

注:增加了乐观锁,我们在写代码的时候一定要注意,单记录更新操作的时候要去判断返回结果(影响行数),不然没改成功,程序是不会抛错的。不像batch接口默认会报错

Step4 预留任务:重写PetItemInventroy的update函数

留个任务,请各位小伙伴自行测试玩玩,这样会更有体感

package pro.shushi.pamirs.demo.core.action;

import org.springframework.stereotype.Component;
import pro.shushi.pamirs.demo.api.enumeration.DemoExpEnumerate;
import pro.shushi.pamirs.demo.api.model.PetItemInventroy;
import pro.shushi.pamirs.demo.api.model.PetTalent;
import pro.shushi.pamirs.meta.annotation.Function;
import pro.shushi.pamirs.meta.annotation.Model;
import pro.shushi.pamirs.meta.common.exception.PamirsException;
import pro.shushi.pamirs.meta.constant.FunctionConstants;
import pro.shushi.pamirs.meta.enmu.FunctionOpenEnum;
import pro.shushi.pamirs.meta.enmu.FunctionTypeEnum;

import java.util.ArrayList;
import java.util.List;

@Model.model(PetItemInventroy.MODEL_MODEL)
@Component
public class PetItemInventroyAction {

    @Function.Advanced(type= FunctionTypeEnum.UPDATE)
    @Function.fun(FunctionConstants.update)
    @Function(openLevel = {FunctionOpenEnum.API})
    public PetItemInventroy update(PetItemInventroy data){
        List<PetItemInventroy> inventroys = new ArrayList<>();
        inventroys.add(data);
        //批量更新会,自动抛错
        int i = data.updateBatch(inventroys);
        //单记录更新,不自动抛售需要自行判断
//        int i = data.updateById();
//        if(i!=1){
//            throw PamirsException.construct(DemoExpEnumerate.PET_ITEM_INVENTROY_UPDATE_VERSION_ERROR).errThrow();
//        }
        return data;
    }

}

图4-1-5-13 重写PetItemInventroy的update函数

注意事项:

如果是自定义页面需要把optVersion字段配置到视图的xml中去,可以配置为隐藏 。例子中因为默认页面已经自动带上了optVersion,所以容易被人忽视掉。

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9280.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Like (0)
史, 昂's avatar史, 昂数式管理员
Previous 2024年5月23日 am8:58
Next 2024年5月23日

相关推荐

  • 资源

    翻译应用是管理翻译规则的应用,以模型为基础、维护字段的翻译值,支持导入、导出 1. 操作步骤 Step1:导出所有翻译项; Step2:线下翻译; Step3:导入翻译项; Step4:刷新远程资源; Step5:页面右上角可切换语言,查看翻译效果。 2. 新增翻译 翻译是具体到模型字段,其中需要区分出是否字典; 源语言、目标语言,是在资源中维护的语言,可在资源中维护需要翻译的语言; 翻译项则是模型字段,默认翻译项为激活状态,关闭后维护的翻译项无效。 3. 导出、导入 不勾选导出:导出所有需要翻译的翻译项,包括模块、字段,源术语、翻译值等,其中如果已经翻译过的内容,会体现在翻译值中; 勾选导出:导出勾选模型的翻译项。 导入:导入翻译项,平台会根据模型拆分为多条数据。 4. 刷新远程资源 导入翻译项后,点击“刷新远程资源”按钮。 5. 查看翻译内容 页面右上角切换语言,查看翻译效果。

    2024年6月20日
    1.4K00
  • 3.5.7.4 自定义页面

    页面是什么 在Oinone前端体系中,页面是一个核心概念,它代表着终端用户所看到的当前视图。这个视图可以有多种形式,主要取决于页面是如何定义和构建的。在深入理解页面之前,我们需要了解两个关键的功能:自定义布局 和 自定义母版。 作用场景 自定义布局 提供了布局调整的强大功能,但在某些情况下,它可能无法完全满足特定的需求。这时,自定义页面就显得尤为重要。自定义页面是对 自定义布局 的补充,允许开发者从更深层次自由地控制和设计用户界面。 当标准布局无法实现所需的视觉效果或功能时,自定义页面提供了更高的灵活性。开发者可以通过自定义页面来实现独特的布局设计,添加特定的交互元素,或者整合复杂的业务逻辑,以创造独特且丰富的用户体验。 自定义页面 自定义视图组件允许开发者定义和使用特定于业务需求的视图布局。下面是一个具体的示例,展示了如何定义、注册和使用通过 setComponent 结合 TypeScript 和 Vue 的自定义视图组件。 示例工程目录 以下是需关注的工程目录示例,main.ts更新导入./view: 图3-5-7-48 自定义页面工程目录示例 1. 定义 TypeScript 组件 首先,我们定义了一个名为 CustomViewWidget 的 TypeScript 组件,并在该组件中通过 setComponent 结合 Vue 单文件组件。 import { BaseElementWidget, BaseElementViewWidget, SPI, ViewWidget } from '@kunlun/dependencies'; import CustomViewVue from './CustomView.vue'; @SPI.ClassFactory(BaseElementWidget.Token({ widget: 'CustomViewWidget' })) export class CustomViewWidget extends BaseElementViewWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomViewVue); return this; } } 图3-5-7-49 定义TypeScript组件代码示例 2. Vue 单文件组件 其次,我们创建了对应的 Vue 单文件组件 CustomView.vue,用于展示自定义视图的具体内容。 <template> <div class="custom-view-wrapper"> <h1>自定义视图</h1> </div> </template> <script lang="ts"> import { defineComponent } from 'vue'; export default defineComponent({ inheritAttrs: false, name: 'ViewComponentVue' }); </script> <style lang="scss"> .custom-view-wrapper {} </style> 图3-5-7-50 定义Vue组件代码示例 3. 注册自定义视图布局 接下来,我们使用 registerLayout 函数注册了一个表格视图布局,并在其中引入了通过 setComponent 结合的自定义视图组件。 import { registerLayout, ViewType } from "@kunlun/dependencies"; export const registerCustomView = () => { registerLayout( ` <view type="TABLE"> <element widget="CustomViewWidget" /> </view> `, { viewType: ViewType.Table, moduleName: 'resource', model: 'resource.ResourceCountryGroup' } ); }; registerCustomView(); 图3-5-7-51 注册自定义视图布局代码示例 效果 图3-5-7-52 自定义页面效果示例 4. 自定义视图在表格中的应用 当我们注册了自定义视图后,它就可以在表格视图中被使用。在表格视图的布局中,我们通过 标签将自定义视图嵌套在表格中,从而覆盖了表格的默认布局 5. 入参一致性 值得强调的是,registerLayout 函数和自定义布局的规则是一致的,这意味着开发者可以在自定义布局中使用与 registerLayout 相同的入参规则,从而实现更加灵活和统一的视图布局设计 与内置组件结合 1. 注册视图元素布局 首先,我们使用 registerLayout 函数注册了一个表格视图的布局。这个布局包含了搜索框、操作栏、以及一个自定义视图组件。 import { registerLayout, ViewType } from "@kunlun/dependencies"; import { CustomViewWidget } from…

    2024年5月23日
    1.8K00
  • 5.2 CDM之工程模式

    两种工程模式介绍 oinone推荐的两种工程模式都保留互联网特性,如跟业务无关的基础平台还是采用平台化思路建设。二种侧重点差异如下 第一种:比较适合企业采用多供应商联合开发场景,先以业务区分,各个业务线有独立的领域平台,最大限度保持不同业务线的独立性,有利于各个业务线独立发展(目前oinone上层星空系列产品采用这种工程模式,因为我们期望的时候帮助企业构建软件生态,必然要考虑不同供应商联合开发场景) 第二种:比较接近传统互联网架构,先按平台领域区分,如商品领域:商品平台做总工程,但里面按业务区分模块分子工程来保持业务相互独立,相对于第一种把领域的代码放一起,带来好处强化大家思考模型通用性。但不适用于跨公司主体间配合。 图5-2-1 Oinone-CDM的两种工程模式 注意事项: oinone兼容传统互联网架构 不管哪种模式,都需要解决CDM的维护问题 CDM维护的常见问题: Q:CDM层缺少模型怎么办? A:CDM层模型是逐步完善和丰富的。如果是特定业务自己需要的模型,这类模型无通用性。则加到自己的工程中;如果是通用的,则架构组确定是否需要纳入到CDM。 Q:CDM层已有的模型缺少字段怎么办? A:CDM层模型的字段也是逐步完善和丰富的,通用的字段在架构组确定后也会被吸收进来 Q:CDM层不同业务线相互影响怎么办? A:扩展字段最好带上自有前缀标志,如果觉得通用则提交架构组走模型缺少字段加入 Q:CDM层某模型新增加了的字段,但原先业务线已经加了相同含义字段 A:业务线可以把自己的字段related到CDM增加的新字段,并做数据迁移

    2024年5月23日
    2.0K00
  • 5.4 基础支撑之商业关系域

    PamirsPartner作为商业关系与商业行为的主体,那么PamirsPartner间的关系如何描述,本文将介绍两种常见的设计思路,从思维和实现两方面进行对比,给出oinone为啥选择关系设计模式的原因。 一、两种设计模式对比 设计模式思路介绍 角色设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的商业主体,并把主体间的关系类型进行整理。 图5-4-1 角色设计模式 关系设计模式思路介绍 从产品角度枚举所有商业角色,每个商业角色对应一个派生的主体间商业关系 图5-4-2 关系设计模式 设计模式对应实现介绍 角色设计模式实现介绍 不单商业主体需要扩展,关系也要额外维护,可以是字段或是关系表。一般M2O和O2M字段维护,M2M关系表维护。 创建合同场景中甲方选择【商业主体A】,乙方必须是【商业主体A】有关联的经销商、分销商、零售商、供应商等,则在角色设计模式下就非常麻烦,因为关系都是独立维护的 图5-4-3 角色设计模式实现介绍 关系设计模式实现介绍 只需维护商业关系扩展 同时在设计上收敛了商业关系,统一管理应对不同场景都比较从容 图5-4-4 关系设计模式实现介绍 二、oinone商业关系的默认实现 首先oinone的商业关系选择关系设计模式 其次模型上采用多表继承模式,父模型上维护核心字段,子模型维护个性化字段。

    2024年5月23日
    2.0K00

Leave a Reply

Please Login to Comment