FEATURE - Change order of execution of liquibase changelogs based on release number #3881
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The order of execution of liquibase changelogs was based on the usage of some master changelog files, defined for each module containing liquibase scripts. These master files defined the order of execution of changelogs but did not prioritize the version number to order the executions of them. Here a new way of executing changelogs is proposed that executes them ordering on the version number. This means that, first, all changelogs of the first release are executed, then all changelogs of the second release, and so on.
Consider the case in which, for example, a certain script for a version changed the name of a table or column, and some liquibase scripts of an older version still reference the old name...it is important to execute those scripts in order of version. This kind of problem could happen taking into account the module "kapua-foreignkeys": think the case where the definition of a foreign key references a table that has been renamed, at a point in future time, by another changelog.
Description of the solution adopted
The kapuaLiquibaseClient has been properly updated to implement the new ordering of changelogs executions.
A global addition to changelog files was needed: the inclusion of a reference to the common.xml file. In fact, before, thanks to the usage of master changelogs files, it could happen that some of the first changelogs were including this common file, and then the subsequent changelogs in the chain would pick it indirectly from the common "context".
Some changelogs were not adhering to the pre-post ordering principle so I modified their names.