I am new to liquibase, and want to check if this is the ideal tool to handle this. Please suggest others outside of liquibase too, if appropriate.
Usecase:
We have a property file that the user can modify. We are looking to solutions on utilizing liquibase to be able to maintain both the user changes as well as the new changes. Is this possible with liquibase? What would the workflow look like?
// Version 1; Release 1
<a>
<b foo="1"></b>
<a>
Now, we roll out Release 1 and the client A has modified foo to be 2 for their purposes; this is what the version 1 now is for the client A after they made their changes. Client B did not do any changes.
// Version 1; Release 1 - at client A
<a>
<b foo="2"></b>
<a>
// Version 1; Release 1 - at client B
<a>
<b foo="1"></b>
<a>
Now in Release 2, we update foo to be 10, and add a new variable 'goo'. So, this is how Version 1 is enhanced
// Version 2; Release 2
<a>
<b foo="10" goo="2"></b>
<a>
Now, when we upgrade the client to version 2, we want to keep the client at their value of foo if it is changed, else switch it to 10. also 'goo' needs to be added.
So, after upgrade, the client file is expected to look like this:
// Version 2; Release 2 - at client A
<a>
<b foo="2" goo="2"></b>
<a>
// Version 2; Release 2 - at client B
<a>
<b foo="10" goo="2"></b>
<a>
======================
The solution we were thinking is to persist this xml into a table, and have liquibase version it. Prior to upgrading the client B, do a dump of their xml to liquibase, and somehow find out that it is different from what was installed. Now, using some diff, enable the above result.
Need some ideas with this please? TIA!
Using PreCondition would work - it can detect user changes without too much complexity as long as you only have a few changes, ie an edge case like what you've described. If it becomes more complex, you may need a different solution or may need to write custom preconditions to accommodate the increased complexity. Documentation: https://docs.liquibase.com/concepts/changelogs/preconditions.html
I also found another question that looks like it might be similar to what you're asking. Link: Can Liquibase handle multiple schemas managed by the same application?
Answer From Nathan Voxland, Liquibase co-founder:
Liquibase can handle objects within multiple schemas and can also manage creating additional schemas as well.
When you connect to the database, Liquibase will create a DATABASECHANGELOG table in the default schema and that schema needs to exist. That table tracks which changeSets have executed, and anything that can be done through SQL can be done within your changeSets.
There are built-in tags for things like createTable, addColumn etc which will make changes in the default schema, but they all have tags such as tableSchemaName that can be used to target the object to a different schema.
If you want to make changes for which there are not built-in tags, you can always use the "sql" tag and specify whatever sql you want, such as create database additional_info