Starting with version 3.0.0 of tia Core Content Server, the database (both protocol and metadata) is managed by Flyway. Flyway is a framework that allows the version management of databases using scripts and records the used ones. This allows applications to self-manage the database even when changing structure changes, migrating data is migrated, or performing complex SQL-based operations are performed.
In contrast to using JPA (Java/Jakarta Persistence API) to manage the database, using Flyway requires SQL scripts for each database supported. tia Core ships with scripts for H2, MSSQL server and Oracle.
Flyway concept and naming patterns
Flyway updates a database from one version to the next using so called migrations. The database migrations are done using use SQL-scripts which are applied and against the usage database. This is recorded tracked in a Flyway history table in the database. Upon each start, the tracked executions in the history table is are compared to the existing scripts and if scripts are missing, the migrations will be against the migrations prepared. If one or more migrations have not been applied yet, they get applied.
We can use two types of files: versioned migrations and repeatable migrations.
...
In order to avoid conflicts with the versioned migrations contained by default, only repeatable migrations should be used. Otherwise it may happen, that the version number of the custom script duplicates the version number of a new script provided by kgs. Leaving a larger gap, e.g. kgs scripts end at V4_0_0 and the custom script starts at V90_0_0, may block kgs scripts later added with V5 and so on. The order of the locations does not matter.
...
For example, using a custom vendor for metaservice database v2, and the scripts are located in /kgs/data/sql/vendor
| Code Block |
|---|
<repo>.metaservice.databasev2.scripts=filesystem:/kgs/data/sql/vendor |
The jar JAR files for both the driver and the flyway Flyway dependency can then be placed in a lib library folder, say /kgs/lib, and then added to the application , depending on the deployment, using the application-wide parameter loader.path, e.g. for container deployments LOADER_PATH=/kgs/lib . Read here how to apply the parameterApplication wide settings.