Sometimes a parameter is only valid to a specific changelog. The changelog parameters are collected properly for all changesets (even if the same key is used).
But if the changesets are created with identical parameter keys, the keys are getting added (redundantly) to the changeLogParameters. So this is good, but now the changelogparameters contain a bunch of identical keys, which are not mappable to a changelog. Far more the findParameter() and the get() returned both the first hit in the list.
This enhancement provides the feature to define if the parameter should be used only for the given changeset or globally like it was before.
I have added a attribute to the XSD so a property has now the attribute: global:boolean
<property .... global="false" />
If the global attribute is ommited the default is global=true. And the code behaves as it was before.
If the global=false is set, the parameter will be only returned, if the corresonding changelog is matching.
There was a minor logical change. The changesetParams have been a bunch of entries independently to a changelog. There was a reference from the changelog to the parameters, but the parameter needs to know who's parent changelog it is. So I have added a reference into ChangeLogParameter class to the changlog itself. (see patch)
For some additional information, I have started this patch after this forum request https://forum.liquibase.org/#Topic/49382000001251007
Quick feedback. Till today we have not faced any issue with the patch. Only the workaround with the XSD is not nice, we have placed it on our webserver for retrieving the changed XSD.
Do you roughly know what time the 4.0 will be released?
I'm gussing 4.0 will be some time in July or August, but it depends on how everything comes together. Very rough at this point.
Do you see any chance to get it incorporated in the 3.4.0 stream?
I am willing to support for the 3.4.0 steam integration.
By the way, we have not faced any issue till today with our envs and with the patched liquibase-version.
Of course we will also help/support on the 4.0 (bigger) rework if support is needed. But it would help us to get it early into the main stream to remove our "patched" versions from the repositories.
As property clashes is very common usecase for generic property names, and with mutiple developers creating changeset this happens too often. This fix (global/local switch) reduces the hassel of correcting property names (unnecessary verbose) which may not make sence.
Can this change be accomdated in 3.4.0. This fix is very important !!
I can see it being helpful, so I merged it into master for 3.4. Thanks for the code and the feedback on the usefulness.