ORM / DataSource Extension
This page explains the current ORM and dynamic datasource extension surface and how a host application can override defaults without breaking the starter contract.
If you want to understand how the built-in dynamic datasource capability works before customizing it, read this first:
Current ORM Entry
The current ORM auto-configuration entry is OrmAutoConfiguration, which mainly creates:
MetaCommandExecutorSaveDefaultValueFiller
MetaCommandExecutor is created only when a Dao bean exists in the host application.
Which DAO Is Used
The explicit ORM property is:
geelato.orm.dao-bean-name=dynamicDao
If the property is configured, ORM binds to the named Dao bean.
If it is not configured and multiple Dao beans exist, the current compatibility order is:
dynamicDaoprimaryDao
Starter JDBC Defaults
When spring.datasource.primary.jdbc-url exists, the starter creates:
primaryDataSourceprimaryJdbcTemplateprimaryDaodbGenerateDao
If spring.datasource.secondary.jdbc-url also exists, it additionally creates:
secondaryDataSourcesecondaryJdbcTemplatesecondaryDao
Dynamic Datasource Extension Points
The dynamic datasource property prefix is:
geelato.datasource.dynamic.*
Important defaults include:
delay-load-data-source=trueenable-jta-transaction=falseenable-seata-proxy=false- default pool settings and
connection-test-query=SELECT 1
Default Definition Source
The current default definition loader is:
PlatformDynamicDataSourceDefinitionLoader
It is created only when the host application does not provide its own DynamicDataSourceDefinitionLoader.
How To Replace It
The host application only needs to provide its own:
DynamicDataSourceDefinitionLoader
Typical scenarios include reading datasource definitions from:
- a configuration center
- YAML or files
- an external registry service
When JTA / Seata Is Enabled
JTA and Seata are not enabled by default.
They are only activated after explicit configuration, for example:
geelato.datasource.dynamic.enable-jta-transaction=true