多环境配置

简介: 当有多个数据源时,需创建多个SqlSessionFactory,每个对应一个数据库。通过SqlSessionFactoryBuilder传入不同环境参数(environment)指定配置,若忽略则使用默认环境。environments中default属性指定默认环境ID,每个environment包含事务管理和数据源配置,环境ID可自定义但必须与默认值匹配。

多个数据源,就创建多个SqlSessionFactory,每个对应一个数据库

为了指定创建哪种环境,只要将它作为可选的参数传递给 SqlSessionFactoryBuilder 即可。可以接受环境配置的两个方法签名是:
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment);
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment, properties);

如果忽略了环境参数,那么将会加载默认环境,如下所示:
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader);
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, properties);

environments 元素定义了如何配置环境:














几个关键点:
● 默认使用的环境 ID(比如:default="development")。
● 每个 environment 元素定义的环境 ID(比如:id="development")。
● 事务管理器的配置(比如:type="JDBC")。
● 数据源的配置(比如:type="POOLED")。
默认环境和环境 ID 顾名思义。 环境可以随意命名,但务必保证默认的环境 ID 要匹配其中一个环境 ID。

相关文章
|
关系型数据库 MySQL 数据库
项目实战24—xxljob控制台不打印日志
项目实战24—xxljob控制台不打印日志
864 0
|
iOS开发 MacOS Windows
解决报错 unable to access jarfile apachejmeter.jar 的一些技巧!🔥
解决报错 unable to access jarfile apachejmeter.jar 的一些技巧!🔥
2857 6
|
前端开发 Java 调度
XXL-JOB 日志表和日志文件自动清理
XXL-JOB 日志表和日志文件自动清理
|
Java 应用服务中间件 Android开发
IDEA 编译时 报 “常量字符串过长” 解决办法
IDEA 编译时 报 “常量字符串过长” 解决办法
4006 0
|
2月前
|
测试技术
为什么要单元测试
单元测试看似费时,实则为开发“加速”。它通过验证代码最小单元的正确性,及早发现问题,减少后期修复成本,提升代码质量与开发效率,让软件迭代更稳更快。
|
2月前
|
开发者
提升代码质量
好的代码应易读、易改、易维护,写单测即是“吃自己狗粮”,从用户视角检验代码。高单测覆盖率的项目更原子化、边界清晰,利于迭代与重构。低圈复杂度意味着逻辑简洁、易于测试,而缺乏单测的复杂代码则难以维护。写单测促使开发者优化设计,降低认知负担,提升整体代码质量。(238字)
|
2月前
|
测试技术 开发者
提升debug效率
单元测试是软件工程的坚实基础,具备快速、稳定、易定位问题的优势。因无外部依赖,执行高效,反馈迅速;稳定性强,不受其他模块变更影响;以最小单位测试,显著缩小问题范围,提升调试效率,是开发者最信赖的测试手段。
|
2月前
|
Java 数据库连接 mybatis
常见配置
当MyBatis配置属性重复时,加载顺序为:先解析properties元素内的属性,再读取resource或url指定的外部文件并覆盖前者,最后读取方法参数传递的属性并覆盖之前配置。优先级:方法参数 > resource/url > properties元素内。
|
2月前
|
敏捷开发 Java 测试技术
提升总体研发效率
高质量单元测试虽短期耗时,但长期显著提升研发效率。它减少调试时间、增强代码变更信心、提升代码自解释性、优化Code Review效率,并支持高频发布。尤其在长周期项目中,ROI随时间持续增长,是保障交付质量与速度的关键实践。
|
2月前
|
Devops 测试技术
为什么需要单元测试
在互联网时代,软件迭代加速,研发需对代码质量与测试负责。测试金字塔强调“单元测试优先”,底层单元测试占80%,为软件打牢基础;中层集成测试占15%;顶层端到端测试仅占5%。该结构源自Google实践,旨在提升研发效率与产品信心,践行“你构建,你测试”的DevOps理念。