AI 时代的数据库应用越来越多地需要存储和检索向量数据。PostgreSQL 的 pgvector 扩展提供了高效的向量存储和相似性搜索能力，但在 Java 侧一直缺少优雅的映射方案。
dbVisitor 6.7.0 新增的 PgVectorTypeHandler 让你可以用 List<Float> 直接映射 pgvector 的 vector 类型，配合 Fluent API 实现完整的向量 CRUD 和 KNN 检索。
动态 SQL 可以通过 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 提出的"双层适配"架构旨在解决这一痛点。
这种设计不仅实现了"One API, Access Multiple Databases"的愿景，还带来了极高的灵活性：开发者既可以享受 dbVisitor 全栈的便捷，也可以仅使用其 JDBC 驱动，在核对 JDBC 能力后，让已有 MyBatis 项目执行受支持的 NoSQL 命令。
有开发者引用物理学隐喻：“粒子的位置与动量不可同时确定”，暗示在框架设计中，通用性与专用性难以兼得。 更有人直言，任何尝试“大一统”的框架，最终都会沦为“四不像”，不仅丢掉了数据库的强事务优势，也没能发挥出例如 Elasticsearch 的能力。
面对这些质疑，dbVisitor 依然坚定地提出了 "One API, Access Multiple Databases" 的愿景。 为什么我敢这么说？今天我们就来拆解这个争议，聊聊 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，实现架构上的统一。
在 Java 开发领域，关系型数据库（RDBMS）的 ORM 工具（如 Hibernate, MyBatis）已经非常成熟。然而，随着 NoSQL 数据库特别是 MongoDB 的普及，开发者对于在 Java 中如何优雅、高效地操作 MongoDB 提出了新的需求。
虽然 MongoDB 是文档型数据库，天生具备 Schema-less 的特性，但在强类型的 Java 语言中，我们依然需要一种机制将 BSON 文档映射为 Java 对象，以便于业务逻辑的处理。这就是 ODM（Object-Document Mapping）应运而生的背景。
本文将探讨 MongoDB 开发中的 ORM/ODM 现状，并介绍一款基于 JDBC 协议的 MongoDB 新工具 —— dbVisitor。
在日常开发中，我们最常使用的动态 SQL 规则是简单的单字段条件，例如 @{and, name = :name}。它的逻辑非常清晰：当参数 name 不为空时，追加 AND name = ?；否则忽略。
但现实世界的业务逻辑往往更复杂。例如，我们需要实现一个组合筛选功能，允许用户通过 "(年龄与性别匹配) 或者 (姓名与ID匹配)" 这样的复合逻辑来查询数据。
本文将介绍如何利用 dbVisitor 规则的高级特性，一行代码搞定这种复杂的嵌套逻辑。
