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)

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