Hint

This article is generated by AI translation.

Data Source Differences

dbVisitor strives to use a unified API to operate on all Relational DataBases and NoSQL DataBases. In practice, data sources still have differences due to their own characteristics. dbVisitor handles these differences mainly in two ways:

• API support: whether a called API is supported on a given data source.
• Database dialect: when using the Fluent API, the same API may generate different commands or syntax depending on the database.

Highlights

If you want to improve these differences, you are welcome to contribute code to the project.

API Support

dbVisitor provides four major APIs under a unified core: Programmatic API, Declarative API, Fluent API, and Mapper File.

For relational databases that rely on SQL, all dbVisitor APIs are available. For finer-grained differences, refer to the Dialect section below.

For non-relational databases, see the guides below for specific differences:

• Redis Specifics
• MongoDB Specifics
• ElasticSearch Specifics

JDBC Feature Support

For non-relational database drivers (Mongo, Elastic), dbVisitor implements the Statement.RETURN_GENERATED_KEYS feature. This means that when using JdbcTemplate or Statement to execute an insert operation, you can automatically retrieve the generated _id.

Database Dialect

Thanks to the SQL standard, most data sources that support SQL and provide JDBC drivers can run normally. The table below lists dialect support differences for the Fluent API.

Database	Pagination	Conflict Strategy	Null Sort	Sequence
DB2	Yes	Into
Apache Derby	Yes	Into
达梦	Yes	Into, Ignore (table needs PK)
H2	Yes	Into		Yes
Hive	Yes	Into
HSQL	Yes	Into
Apache Impala	Yes	Into
IBM Informix	Yes	Into
人大金仓	Yes	Into
MariaDB	Yes	Into
MySQL	Yes	Into, Update, Ignore	Yes
Oracle	Yes	Into, Update, Ignore (needs PK)
Phoenix	Yes	Into
PostgreSQL	Yes	Into, Update, Ignore
SQLite	Yes	Into
SQL SERVER	Yes	Into
虚谷数据库	Yes	Into