[#255] Fixing 'liquibase' domain issues against Core 2.5.5+. #256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…Files relative to changeset
mseaton
changed the title
mseaton
changed the title
mks-d
changed the title
mks-d
changed the title
ibacher
approved these changes
Nov 8, 2023
|
@mseaton So, I'm running into issues with this change. Specifically, the |
That isn't an absolute path @ibacher . It's a path relative to the application data directory, specifically "configuration/pih/liquibase/xxx.xml" If it is helpful @ibacher , we are successfully using the Iniz liquibase domain in our Rwanda distribution here. |
|
@mseaton Yeah, I discovered a different bug in core that needs fixing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 genesis of this is trying to use the liquibase domain on an OpenMRS 2.5.x instance to load a liquibase file that contains "sqlFile" changesets which refer to sql files at a relative path, which fails due to an NPE.
This is something I had noticed a long time ago, and we worked around in our main PIH EMR distribution by a) patching core, and b) using a custom liquibase loader at startup. You can see that code here, which has been used successfully in that distribution for years. This also addresses an issue that I brought up on the core ticket which provided the necessary fixes in 2.5.x and beyond, where we discovered an issue with the previous use of absolute file paths in the liquibase changelog. Basically, the use of absolute paths made the changesets non-portable, so migrating (say) from
/home/tomcat7/.OpenMRSto/home/tomcat8/.OpenMRSand then restarting your sever would result in all of the changes in the liquibase file getting re-executed, whether they already had been or not, since the change in file would be interpreted by liquibase as a totally new set of changesets. This could have very bad consequences if, for example, there are data migration or data cleanup changesets that were intended to run only once and never again and don't have sufficient preconditions on them.This PR aims to solve these issues for implementations that have reached OpenMRS 2.5 (although this will only work for OpenMRS 2.5.5+ due to where the core patch was installed).
@mks-d / @Ruhanga / @ibacher / @rbuisson let me know what you think.