"Help People Upgrade to Platform 2.x" Sprint Announcement

mozzy · May 15, 2018, 6:31am

i have upgraded formfiletr moduleto run on 2.0.5 and it runs succesfull . it has also run succsefully on 2.1.3

https://github.com/openmrs/openmrs-module-formfilter/pull/1

ningosi · May 15, 2018, 7:38am

This image shows what is left after manually dropping the constarint

. And to restore it I tried writing this and got this error ERROR 1215 (HY000): Cannot add foreign key constraint . I get the same error when I write this, and that is why I ended up checking online for explanation and that is why I landed on stack overflow

ningosi · May 15, 2018, 7:50am

So far I have been able to upgrade my 1.11.5 database to 2.0.5 platform(though by manually disabling the constraints on reporting table), some of the community modules that had issues earlier are running - I needed to upgrade them to the newest versions(database backup and patient flags), some of them are in snapshot version(they may need to be released), I have seen @mozzy has a fix for the form filter module to run on 2.x which will need to released and merged for testing. a blocker is to restore the earlier disabled constraints, Some of our modules are NOT compatible(We will need to fix them to run on 2.x). I appreciate the help from the community to make it success.

darius · May 16, 2018, 3:50am

I notice that the constraint name you’re trying to add has been replaced by something newer in the reporting module.

You might also try creating an index first, i.e. try to replicate these two liquibase changesets:

github.com

openmrs/openmrs-module-reporting/blob/master/api/src/main/resources/liquibase.xml#L484-L502


      
          		<dropForeignKeyConstraint baseTableName="reporting_report_design_resource" constraintName="retired_by for reporting_report_design_resource" />
          	</changeSet>
          
          	<changeSet id="drop_requested_by_for_reporting_report_request" author="mgoodrich">
          		<preConditions onFail="MARK_RAN">
          			<foreignKeyConstraintExists	foreignKeyTableName="reporting_report_request" foreignKeyName="requested_by for reporting_report_request" />
          		</preConditions>
          		<dropForeignKeyConstraint baseTableName="reporting_report_request" constraintName="requested_by for reporting_report_request" />
          	</changeSet>
          
          	<changeSet id="drop_creator_for_reporting_report_processor" author="mgoodrich">
          		<preConditions onFail="MARK_RAN">
          			<foreignKeyConstraintExists	foreignKeyTableName="reporting_report_processor" foreignKeyName="creator for reporting_report_processor" />
          		</preConditions>
          		<dropForeignKeyConstraint baseTableName="reporting_report_processor" constraintName="creator for reporting_report_processor" />
          	</changeSet>
          
          	<changeSet id="drop_changed_by_for_reporting_report_processor" author="mgoodrich">
          		<preConditions onFail="MARK_RAN">

ningosi · May 16, 2018, 8:40am

So I did the following; I dropped the old index created on that table from the database, dropped the changeset in the liquibasechangelog table, stopped and restarted reporting module. The index got recreated with the correct name. I ended up writing this changeset to effect the foreign key constraint on the index created and resulted into the same error when trying to upload the change

darius · May 16, 2018, 5:45pm

Thanks to @tendomart and @mozzy for taking care of the Patient Flags and Form Filter modules!

Still open for work is RCM-106 (Cohort Builder not working on Platform 2.1+), which is an important bug to fix, for implementations beyond eSaude. (@ssmusoke perhaps there’s a UgandaEMR-focused dev who might look at this, to ensure you all would be able to upgrade from 2.0.x to 2.1.x?)

@ningosi can you document steps that someone else could take to reproduce this issue using the SDK? That might help someone help you. E.g. it could be to use the SDK to create a server with RefApp 2.4 (which is on platform 1.11.6), then explain how to save a cohort definition through the UI, then to upgrade to the latest RefApp release. (I’d document this on TRUNK-5383)

mozzy · May 17, 2018, 10:59am

the Filter Module runs loads properly but wen i click on a single form …it brings this error https://hastebin.com/obukokiheb.swift. any clue on how i ca go about it?

tendomart · May 18, 2018, 9:32am

@darius , @ningosi Patient Flags Already Released to Bintray https://bintray.com/tendomart/omod/PatientFlags/2.0.0?sort=&order=#files/

but not yet released Through to CI.

dkayiwa · May 18, 2018, 12:11pm

@tendomart released before your pull request is merged?

tendomart · May 18, 2018, 1:17pm

@dkayiwa am the Reverting the PR, there was no need to add “2.x” to the config file.

tendomart · May 18, 2018, 1:26pm

I did test the omod at my local instance before releasing it at Bintray , that is what was remaining for the Ticket.But i guess it’s bad practice since you have raised the concern,will try to avoid it next time.

darius · May 18, 2018, 7:15pm

@tendomart the Patient Flags module is already in OpenMRS’s bintray here: https://bintray.com/openmrs/omod/patientflags

So the way to release the new version is via CI (which will automatically do a maven release, which will automatically be picked up by bintray, though possibly it takes some hours for this)

tendomart · May 20, 2018, 8:15am

@darius oh thanks. i had not considered that.

do we need to do a few updates here

https://wiki.openmrs.org/display/docs/Module+Release

https://wiki.openmrs.org/display/docs/Maven+Release+Process

mozzy · May 21, 2018, 1:12pm

the filter module still got issues. i tried to change the aproach on how to deal with the hibernate 3/4 incompatibilities here

but i still get the same error

darius · May 24, 2018, 4:56am

I’d like to give an update/summary on this sprint (since we are actually 5 days past the scheduled end date).

So far…

Done:

PLAT-36 - we determined that the Database Backup module already runs in Platform 2.x
PLAT-37 - we determined that the Data Entry Statistics module already runs in Platform 2.x
TRUNK-5383 - we researched a particularly tricky issue with the reporting module and openmrs-core upgrades, and determined that it won’t occur with current versions of reporting, so this is safe for eSaude to do a quick-fix for

In Progress:

PLAT-38 @tendomart is working on releasing the Patient Flags module
PLAT-39 @mozzy is working on upgrading the Form Filter module

And we have two tickets that did not get picked up:

RCM-106
TRUNK-5384

@ningosi can you please give a summary of where eSaude stands as far as upgrading their system to run on Platform 2.x?

Others who may also be working in parallel are welcome to share too.

tendomart · May 24, 2018, 12:37pm

@darius my system has been down for the last two days.Still trying to get things fixed then i’ll clear up the PR.But about testing i tested Patient Flags on Platform 2.0.6 ,the only remaining thing was Release via CI, then have it closed.

ningosi · May 24, 2018, 2:03pm

Darius,

So far I have tested all the community modules we use for esaude and found them working on platform 2.0.5 and manged to upgrade our database(manual fixes were required though for reporting) to that as well. What is remaining now is to fix all our custom modules to be compatible with 2.x, then fire up a demo server for folks to try and simulate what they have been doing with the previous version just to make sure everything is OK and are NOT interrupted from normal. Then depending on the user testing experience, we will make a decision to roll out to other facilities.

Many thanks to all that participated to help esaude learn and get to platform 2.0.5, I believe it will be smooth to get to 2.1.x with minimal adjustments.

Regards

ssmusoke · May 25, 2018, 9:20am

@tendomart Patient flags already works on 2.0.6 since we use it with the current UgandaEMR version in development and on the demo site http://bit.ly/ugandaemr-demo

darius · May 25, 2018, 11:25pm

Thanks @ningosi for eSaude’s help in providing us a target to work towards, and please do continue to keep us informed about your progress in doing the upgrade.

And if other implementations want help in doing an upgrade, please reach out to the community as well!

mozzy · May 28, 2018, 11:49am

thx @darius too, i finally got done with the form filter module