Proposing a sprint to help people upgrade to Platform 2.x (Mozambique tried to upgrade to Platform 2.x, but was blocked for various reasons)

Continuing the discussion from Sync2 Testing Report:

We actually have very little specific insight at the shared OpenMRS level about why people have or haven’t upgraded from Platform 1.x to 2.x, so thank you very much @ningosi for sharing this analysis!

It has been 1.5 years since Platform 2.0 was released, and uptake of Platform 2.x has been slower than I had hoped (perhaps unrealistically). Personally I think it’s time to invest some community effort into addressing all the sorts of hurdles that people have faced in getting to the latest Platform releases.

I propose that we do a community sprint, and spend a couple of weeks of focused volunteer effort addressing all sorts of issues related to “helping people get to Platform 2.x.” Thoughts?

Some of the issues that Nicholas mentions here could easily be addressed in that kind of a sprint.

I just commented on the linked Talk topic. I think we should put a workaround for this in openmrs-core, since it affects anyone using the reporting module (including anyone running the refapp).

Historically we have not tried to proactively upgrade any of the non-refapp modules for Platform 2.x, but I’m proposing that we do upgrade and test a bunch of modules in this sprint that aren’t in the refapp and haven’t been community-supported.

@ningosi did you get to test the snapshot version, and did it work for you?

It seems like an easy task to release a version of patientflags that removes the logic dependency. @mogoodrich thoughts? Or are you no longer really the owner of this module, and it just requires another volunteer to do the release?

Would be worth upgrading this in a sprint.

You’re not using the logic module directly, right? So as long as we drop the logic requirements from other modules, that’s good enough? What are all those modules? Anything besides patientflags mentioned here?

I recall this is quite old, but it could still be upgraded in a sprint.

Should be upgraded in a sprint.


We are in the process of upgrading the PIH EMR to 2.1.x and I’ve been meaning to post some of the issues we’ve run into but haven’t gotten around to it so I’ll add them here before a procrastinate again… :slight_smile: if we’ve got a better place for these let me know and I’ll move them there.

  • We were upgrading to 2.1, and ran into many cases where REST resources hadn’t been defined to support for 2.1 and so we had to modify them, for example:

We probably should just change all these to be “2.*” because we are going to run into the same issue with 2.2. Thoughts/downsides @darius and @raff?

  • We ran into a separate liquibase issue than the one mentioned above due to an inconsistency in the way a changeset was backported to different versions of the code (see my comments on TRUNK-3422). Luckily, the workaround was simply to remove the entries from the liquibasechangelog table because the changesets can be rerun again without issue, so you’d manually execute this one line before peforming the update:

delete from liquibasechangelog where ID like 'TRUNK-3422%';

  • Schema changes to the obs table can be problematic when you have a very large obs table. We have a obs table with 27 million obs in it, and there were five schema changes to it that each took close to an hour, if not more, to run. As we are using OpenMRS in a hospital with an ED, we couldn’t afford to have 5+ hours of downtime. I’m currently testing this now, but it looks like we are going to be able to use Percona Toolkit to run those five changesets on our system while it’s online, prior to doing the upgrade. Thoughts on a good place for me to document this? (Also, we should really try to keep schema changes to the obs table to a minimum going forward)

Take care, Mark

1 Like

One other point:

  • Somewhere between 1.10.x and 2.1.x validation was added to make sure that if a concept_numeric has allow_decimal=false, then you can’t save obs under that concept with a decimal value. This is correct, but if you were previously saving decimal values against concept_numerics with allow_decimal=false you may run into validation errors after the upgrade

Bringing in some additional information from a PM with @aramirez (who is also looking to upgrade to Platform 2.x now that Sync 2 will support this):

Per this other thread, Daniel has done a fix for this, it just needs to be tested by some real user: Cohort builder error on openmrs 2.1.2. (i.e. you’ll be able to go all the way to 2.1.

I would expect that Address Hierarchy and IDGen should work (because PIH has already tested these in preparation for their upgrade), and XForms should work (because it’s part of the reference application).

I don’t know about custombranding (I could imagine it getting broken when we pulled the UI into the legacyui module with platform 2.0), but if it’s working for you, great!

For reportingcompatibility, if you find any errors beyond the one discussed above about Cohort Builder, then please share.

Sorry that we dropped the ball when you pointed this bug out last year. I just asked you a question on docs and resources migration (which will tell us what kind of fix is appropriate).

I don’t know the answer to this, since as a developer I’m not using tomcat. I’m sure someone else can answer this though.

@ningosi Data Entry Statistic Module is working for me on my upgrade from 1.9.8 to 2.1.2

We have already migrated to 2.1.2 to be honest it was not easy. First there were changes in the obs table and when you have close to 260 millions rows in the obs table that is a challenge. Then there is the issue with modules we had to patch some of the modules to make them compatible with 2.x.x and retire those we determined were not worth the effort. We can share the obstacles we faced during the process and possible solutions.

For the obs table this scripts should help.

is the last word on this line correct? Is it supposed to be concept?

This is a limitation. We have some numeric observations that are store with decimal point, some implementations have been forced to effect that by adjusting their concept dictionary thereby deviating from the normal process of loading the dictionary and decide to maintain their own. My advice would be, we allow decimal for this field.

@ningosi That script was generated by running SHOW CREATE TABLE obs; So it will be safer for someone to run this against their production obs table to get the correct create script. Another thing to be careful with is the AUTO_INCREMENT value.

So, what do people think about this?

1 Like

Looks like a great idea!

@achachiez, it would be great if you can share more about your experience!

If we do this sprint after beginning of May, some of the Mozambique eSaude team can join in. @valvijo @ningosi @carina @yassin @hmutaquiha @minoneves - what do you all think?

We can set the timing for this as needed to maximize who can participate, and it would be great if a team that actively would like to upgrade to Platform 2.x is participating! (Can you give more clarity about what “after the beginning of May” actually means?)

Any other groups and individuals interested in participating?

I would suggest that if you generally want to upgrade to the latest OpenMRS Platform releases, you would do well to schedule trying to do this simultaneously with others on this sprint, so that we can identify, analyze, and fix any upgrade issues quickly with everyone focused on it.

I am starting to create/collect tickets for this sprint (and I created a label in JIRA: help-upgrade-platform-2):

  • TRUNK-5383 - Automatically handle upgrading data model to 2.0 even when the reporting module is installed
  • RCM-106 - Patient searches return 0 results on platform 2.1
  • TRUNK-5384 - Use new Implementation ID server URL, and support redirects and https in our custom HttpClient class

@ningosi there are some things I want to confirm with you:

Still to do:


I am interested and I want to participate even though I have done an upgrade several times with the help of @dkayiwa, also I have prepared a brief documentation of upgrading process and challenges I have encountered together with specific solutions. I can send this document If you think it can be of some help.


The patient flag rest module is the custom module for esaude that extend patient flag module for reporting on our POC which is javascript front end, for this to work on 2.x we just need a release of patientflags module that is NOT depended on logic module.

Yes. the form filter module is this one, as you have highlighted.

And as @janflowers puts it, it will be good for the testing candidates to be included in the whole process of upgrade planning.

This will be helpful for us to participate fully. We might contribute items that will help to improve the product for other implementers to ride on.

1 Like

@ningosi Why not just integrate the eSaude REST code into the patient flags module (which already runs on 2.x) so that you do not need an extra module to maintain?

@janflowers @valvijo @ningosi @carina @yassin @hmutaquiha @minoneves

  1. What additional functionality does Mozambique implementation have that can be brought back into the OpenMRS Reference Application main line

  2. Can you provide a comprehensive list of blockers that can be considered

  3. Please can you join the Reference Application 2.8 planning design call tonight as we seek to prioritize what can get done in this release, any spill overs go to the next release.

@ningosi I have just landed on this now, in UgandaEMR we can store numeric concepts with a decimal point - is it the concepts that you mean here?