ZhaoYongChun

公元前日期在数据库中的处理是一个被长期忽视的难题。Java 的 ISO 8601 年份表示法与数据库的日期系统存在根本性差异，导致跨系统传递公元前日期时经常出现"偏移一年"或"偏移一天"的诡异 Bug。

dbVisitor 6.7.0 新增了 JulianDayTypeHandler 和 PgDateTypeHandler 两个处理器，分别从"跨库通用"和"PostgreSQL 原生"两个角度彻底解决这个问题。

在日常开发中，"查两列，组成 Map"是一个高频操作：ID 到名称的映射、编码到描述的映射、配置键到值的映射…… 以往你需要查出列表再手动遍历构建 Map。

dbVisitor 6.7.0 新增的 queryForPairs 方法，一行代码直接拿到 Map<K, V>。

AI 时代的数据库应用越来越多地需要存储和检索向量数据。PostgreSQL 的 pgvector 扩展提供了高效的向量存储和相似性搜索能力，但在 Java 侧一直缺少优雅的映射方案。

dbVisitor 6.7.0 新增的 PgVectorTypeHandler 让你可以用 List<Float> 直接映射 pgvector 的 vector 类型，配合 Fluent API 实现完整的向量 CRUD 和 KNN 检索。

作为一名 Java 开发者，你一定经历过被 MyBatis XML 支配的恐惧。

当你打开一个 UserMapper.xml，迎面而来的是几百行甚至上千行的 <if>, <where>, <choose>, <foreach> 标签。原本清爽的 SQL 语句被这些 XML 标签切割得支离破碎，仿佛老太太的裹脚布——又臭又长。

如果你也受够了在 XML 标签里写逻辑，受够了为了一个简单的非空判断就要写三行 XML，那么请继续往下看。dbVisitor 的动态 SQL 规则机制，也许就是你一直在寻找的"剪刀"。

dbVisitor 是一个旨在提供统一数据库访问体验的 Java 工具库。随着对 MySQL、PostgreSQL 等关系型数据库以及 MongoDB、ElasticSearch 等 NoSQL 数据源支持的不断深入，底层的方言系统（Dialect System）面临着越来越复杂的挑战。

近期，我们对 dbVisitor 的方言系统进行了一次深度的架构重构。本次重构不涉及功能变更，旨在解决旧架构中存在的抽象割裂问题，将“方言元数据”与“命令构建能力”高度内聚。

本文将深入探讨这次架构演进背后的思考、实施方案以及带来的显著优势。

本文将深入解析 dbVisitor 独特的"双层适配"架构，揭示其如何通过应用层与协议层的双重抽象，打破 RDBMS 与 NoSQL 的壁垒。

摘要​

在使用 Java 进行现代应用开发时，混合使用关系型数据库（如 MySQL、PostgreSQL）和非关系型数据库（如 MongoDB、Elasticsearch）已成为常态。 然而，这种混合架构往往导致技术栈割裂：开发者需要在 JDBC/MyBatis 和各种 NoSQL 专有客户端之间频繁切换。

dbVisitor 提出的"双层适配"架构旨在解决这一痛点。

• 第一层（应用适配）：在 API 层面，通过统一的 LambdaTemplate 和 Mapper 接口屏蔽底层语法差异（SQL vs DSL）。
• 第二层（协议适配）：在驱动层面，实现了标准的 JDBC 接口，将 NoSQL 数据源封装为标准 JDBC 驱动。

这种设计不仅实现了"One APIs Access Any DataBase"的愿景，还带来了极高的灵活性：开发者既可以享受 dbVisitor 全栈的便捷，也可以仅使用其 JDBC 驱动，让现有的 MyBatis/Hibernate 项目瞬间具备操作 NoSQL 的能力。

有开发者引用物理学隐喻：“粒子的位置与动量不可同时确定”，暗示在框架设计中，通用性与专用性难以兼得。 更有人直言，任何尝试“大一统”的框架，最终都会沦为“四不像”，不仅丢掉了数据库的强事务优势，也没能发挥出例如 Elasticsearch 的能力。

面对这些质疑，dbVisitor 依然坚定地提出了 "One APIs Access Any DataBase" 的愿景。 为什么我敢这么说？今天我们就来拆解这个争议，聊聊 dbVisitor 敢于挑战“大一统”的底气究竟在哪里。

数据访问层（DAL）技术已经非常成熟，从最早的 JDBC 到 Hibernate、MyBatis，再到 Spring Data JPA。我们习惯了用这些框架处理数据。然而，当我们把目光投向“数据”本身的变化时，会发现这些经典的框架似乎正逐渐变为“老一代”。

新一代的挑战不再仅仅是如何优雅地写 SQL，而是如何用统一的方式访问那些不再仅仅存储在关系型数据库中的数据。

在 Java 生态中，操作 ElasticSearch 最常见的方式莫过于使用官方的 elasticsearch-java (或旧版的 RestHighLevelClient) 或者 Spring 家族的 spring-data-elasticsearch。这些工具非常强大，但对于习惯了关系型数据库（RDBMS）和 MyBatis 开发模式的开发者来说，切换到 ElasticSearch 往往意味着需要适应一套全新的 API 和思维模式（DSL 构建、Builder 模式等）。

特别是在一个混合架构的项目中，如果同时存在 MySQL 和 ElasticSearch，数据访问层的代码风格割裂感会非常强：一边是 MyBatis 的 Mapper 接口和 XML，另一边是复杂的 DSL 构建代码或 Repository 接口。这种差异不仅增加了学习成本，也让诸如“分页查询”这样的通用功能难以统一实现。

本文将介绍如何使用 dbVisitor，以一种“类 MyBatis”的方式来操作 ElasticSearch，实现架构上的统一。

在 Java 生态中，操作 MongoDB 最常见的方式莫过于使用官方的 mongo-java-driver 或者 Spring 家族的 spring-data-mongodb。这些工具非常强大，但对于习惯了关系型数据库（RDBMS）和 MyBatis 开发模式的开发者来说，切换到 MongoDB 往往意味着需要适应一套全新的 API 和思维模式。

特别是在一个混合架构的项目中，如果同时存在 MySQL 和 MongoDB，数据访问层的代码风格割裂感会非常强：一边是 MyBatis 的 Mapper 接口和 XML，另一边是 MongoTemplate 的链式调用或 Repository 接口。这种差异不仅增加了学习成本，也让诸如“分页查询”这样的通用功能难以统一实现。

本文将介绍如何使用 dbVisitor，以一种“类 MyBatis”的方式来操作 MongoDB，实现架构上的统一。