Skip to main content

Datasource Differences

dbVisitor strives to use a unified API to operate all Relational Databases and Non-Relational Databases. However, in practice, data sources still have individual differences due to their own characteristics. The way dbVisitor handles differences is mainly reflected in two aspects:

  • API Support, refers to whether the called API is supported on a certain data source.
  • Database Dialect, refers to the use of different commands or syntax when operating different databases with the same API when using Fluent API.
Feature

If you want to modify these differences, you can participate in the project and contribute your improved code.

API Support​

dbVisitor's API designed for usage under a unified kernel architecture is mainly divided into 4 types: Programmatic API, Declarative API, Fluent API, Mapper File.

For Relational Databases based on SQL language, all APIs provided by dbVisitor can be used. For specific database differences, refer to the description in Database Dialect in this article.

For Non-Relational Databases, you can learn more about the differences through the following guidelines:

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 get the generated _id.

Database Dialect​

dbVisitor has intelligent dialect inference capabilities. When creating data operation interfaces, it automatically identifies the target database type based on the JDBC URL and configures the best dialect. Therefore, for the databases listed in the table above, you usually do not need to perform any manual configuration.

If your application scenario is special (e.g., using an unsupported database, middleware proxying the JDBC URL), you can explicitly specify the dialect through configuration. Specifying the dialect supports Dialect Alias (e.g., mysql) or Dialect Fully Qualified Class Name.

The following table lists the functional support differences of dbVisitor's built-in database dialects for the Fluent API.

Config KeyDatabasePaginationConflict StrategyNull Sort StrategySequence
db2DB2SupportedInto
derbyApache DerbySupportedInto
dmDamengSupportedInto, Ignore (Table needs Primary Key)
h2H2SupportedIntoSupported
hiveHiveSupportedInto
hsqlHSQLSupportedInto
impalaApache ImpalaSupportedInto
informixIBM InformixSupportedInto
kingbaseKingbaseSupportedInto
mariadbMariaDBSupportedInto
mysqlMySQLSupportedInto, Update, IgnoreSupported
oracleOracleSupportedInto, Update, Ignore (Table needs Primary Key)
postgresqlPostgreSQLSupportedInto, Update, Ignore
sqliteSQLiteSupportedInto
sqlserverSQL SERVERSupportedInto
xuguXugu DBSupportedInto
mongoMongoDBSupportedInto
elastic6ElasticSearch 6SupportedInto
elastic7ElasticSearch 7+SupportedInto