FWIW, all reference application modules start up properly on platform 2.4 as you can see here: https://qa-refapp.openmrs.org/
The necessary fixes were done months ago. For modules that have not yet been released, you need their snapshot versions, like was the case of the adminui module, before i released it today.
@ibacher, @dkayiwa and @gcliff
After the Liquibase overhaul was merged to master in May 2020, I fixed a few OpenMRS repositories where data was loaded from sql files and records were missing from the liquibasechangelog table.
More recently @gcliff uncovered further issues when building an openmrs-standalone release based on openmrs-core 2.4.x. Most of them were fixed and one more fix is pending for starting openmrs-standalone in expert mode.
Regarding the PIH EMR on 2.4.0 core, could you please
That would allow me to look into the matter and provide a fix.
Thank you, Wolf
Good timing @wolf @ibacher I was just looking into it.
So, it looks like the “getInitialLiquibaseSnapshotVersion” runs through all the liquibase files for each version of OpenMRS in search of the version that was used to initialize OpenMRS, making the assumption that whatever file has all of the changesets run is the version.
In this case, for some reason on my local dev environment (and I also checked on one of our staging servers) all the 1.9.x changesets have been run, except for these two:
<changeSet id="20120529-2230" author="mvorobey">
<addForeignKeyConstraint constraintName="privilege_which_can_view_encounter_type" baseTableName="encounter_type" baseColumnNames="view_privilege" referencedTableName="privilege" referencedColumnNames="privilege"/>
</changeSet>
<changeSet id="20120529-2231" author="mvorobey">
<addForeignKeyConstraint constraintName="privilege_which_can_edit_encounter_type" baseTableName="encounter_type" baseColumnNames="edit_privilege" referencedTableName="privilege" referencedColumnNames="privilege"/>
Not sure why these haven’t been run, perhaps the were mistakenly added to the file at a later date or something?
But presumably they should be ignored, and OpenMRS should pick up that it was, indeed, the 1.9.x version that was used to initialize the DB?
Take care, Mark
So those two changes appear to have been added as part of TRUNK-3377, and as such were actually first around in 1.11 rather than 1.9.
Confusingly, both of those changesets appear to just apply foreign key constraints that already existed.
Probably the detective can just be updated to consider these “vintage” or “ignorable”?
@ibacher @mogoodrich i have tried running the reff app distribution 2.11.0-snapshot on the recently released core 2.4.0-alpha via tomcat and it works fine
However the same 2.11.0-snapshot distribution fails to run when using the sdk on 2.4.0-alpha as seen here
logsThanks for sharing the details and logs.
Probably the detective can just be updated to consider these “vintage” or “ignorable”?
That sounds like the best approach to me.
When the ChangelogDetective tries to find the baseline snapshots, it looks into all versions, starting at the most recent and finishing with 1.9.x. Instead it should stop at 2.1.x (which is the Liquibase snapshot that comes after 1.9.x) and if there is no match just return 1.9.x as the baseline snapshot.
This should work for all versions that were initialised prior to 1.9.x as all liquibase-update-to-latest-x.y.z.xml change log files would be considered when updating the OpenMRS database.
I can look into that over the weekend.
Just had a look at the logs, the error shown in the screenshot of the initialisation wizard reads
WARN - InitializationFilter$InitializationCompletion$1.run(1724) |2020-10-21T16:24:13,562| Error while
trying to update to the latest database version org.openmrs.util.DatabaseUpdateException: There was an error while updating the database to the latest. file: org\openmrs\liquibase\updates\liquibase-update-to-latest-2.0.x.xml. Error: org\openmrs\liquibase\updates\liquibase-update-to-latest-2.0.x.xml does not exist
This is not related to the ChangeloDetective but an actual changelog file seems to be missing.
Not sure how that could happen, could you please unpack the jar and let me know the content of the org/openmrs/liquibase/updates folder inside the jar? It should contain the missing file.
@wolf thanks for the feedback on this
i dont have a jar file to unpack in the folder structure of the reff app server 2.11.0-snapshot that am running
May be you can clarify abit if am not getting u
Thanks
The “jar” file in this case is the “war” file "openmrs-2.4.0-alpha.
I’m wondering if this has to do with the use of File.separator in the ChangeLogVersionFinder, since I see @gcliff is getting Windows file separators (\) instead of (/). That would work for reading from the file system, but not from the classpath.
Well spotted, using File.separator instead of hard coding forward slashes had actually been one of the review comments on the original pull request.
But in other places in the log the backslashes are working well, for example:
INFO - ChangeLogDetective.getInitialLiquibaseSnapshotVersion(93) |2020-10-21T16:24:12,650| file 'org\openmrs\liquibase\snapshots\core-data\liquibase-core-data-1.9.x.xml' contains 0 un-run change sets
So unpacking the war file and inspecting its content would still be useful.
Definitely agree with that. What got me wondering about the file separators was actually noticing that Liquibase normalised them to /, but at the point where the exception occurred, we seem to be passing the raw changeLogFile string.
Actually, looking at this a bit deeper, is there any reason that line 244 of DatabaseUpdater couldn’t just be replaced with:
DatabaseChangeLog changeLog = liquibase.getDatabaseChangeLog();
?
@wolf when i open the 2.4.0-alpha war file i see this K xž5Q8ƒÆêR R META-INF/MANIFEST.MFóMÌËLK-.ÑK-*ÎÌϳR0Ô3àår*ÍÌIÑõ - Pastebin.com
@gcliff To actually “see” what’s in the WAR, copy the file and change the extension to .zip (WARs and JARs are just zip files with a defined folder structure).
@ibacher @wolf i have zipped the war file but on openning it i still get back to the war file and its contents i shared above as seen below
I submitted two PRs (for openmrs-core master and 2.4.x) that introduce 1.9.x as default value when looking for the Liquibase snapshot that was used to initialise the OpenMRS database.
This change accomplishes two things:
ChangeLogDetective.The pull requests are https://github.com/openmrs/openmrs-core/pull/3608 and https://github.com/openmrs/openmrs-core/pull/3609.