eSaude EMR Platform Upgrade Notes

Overview

The original version of the eSaude EMR Platform was built on top of OpenMRS v1.9.2. Since the OpenMRS community only supports the last three major releases of it’s platform, version v1.9.x has now reached it’s end of life. See the official announcement here.

Therefore, it is necessary to upgrade to a supported version of the OpenMRS platform. Although v1.12.0 is the latest release, the eSaude community is opting to stick to the better tested 1.11.x branch, and we will therefore upgrade to v1.11.6.

  • Instructions

Troubleshooting

The following issues have been experienced by some implementations during upgrades. If you experience any of these, please read the notes below.

If you experience errors that are not listed below, please send an email to helpdesk@esaude.org or get in touch using one of the +eSaude Communication Tools.

reporting_report_design_ibfk_3 SQL Constraint Error


Overview

In v0.7.6 of the Reporting Module (specifically this commit), a foreign key was added to the reporting_report_design table to the serialized_object table, which referenced the uuid in the serialized_object table.

Problem

When liquibase changeset 20160202-1743 is being execute during the v1.11.5 platform upgrade, an error is being thrown at this line:

<addNotNullConstraint tableName="serialized_object" columnName="uuid" columnDataType="char(38)" />

The full error is:

Error executing SQL alter table reporting_report_design modify report_definition_uuid char(38) not null: Cannot change column 'report_definition_uuid': used in a foreign key constraint 'reporting_report_design_ibfk_3'

I think the issue is that from v0.7.7, a clean install of the reporting module never referenced serialized_object by  uuid, so all future versions of the reporting module assumed the foreign key was correct, but no changeset explicitly fixed the key as created in a v0.7.6 install.

⚠️ It is still unclear how the key got the name reporting_report_design_ibfk_3, since both the sqldiff and liquibase files always give keys explicit, descriptive names. Further, every version of our clean database has the correctly named keys. ⚠️

Solution (WIP)

For now it is safe to remove the offending foreign key as follows:

ALTER TABLE reporting_report_design DROP FOREIGN KEY 'reporting_report_design_ibfk_3';

📢 For further discussion, see this Talk thread.

There are actually two issues here:

  1. The foreign key is preventing the upgrade (see OpenMRS ticket REPORT-769)
  1. Our reporting table constraints are incorrectly named