Recently we did a DHIS upgrade test to upgrade our instances from 2.21 to 2.24. We started with 2.21 instance having good amount of metadata. We sequentially upgraded that instance to 2.24 by following the upgrade scripts for each DHIS version.
From that upgraded instance, an export was taken using the new exporter (/api/24/metadata). It was then imported to another fresh instance on 2.24 using the new importer. Below are our findings.
Most of the blockers were due to introducing of new constraints across DHIS versions. The upgraded instance did not have these constraints but the new fresh instance had them so it was preventing the import.
ex: shortName in dataelements table became unique
numerator is required for all indicators
dataelement_operand_unique_key (it is removed now)
We manually corrected our data so it abides as per the constraints. The list of constraints introduced in a DHIS version would be part of upgrade notes. Is this a right assumption?
Allow for many-to-many between Group and GroupSet. If we have groups which are part of multiple group sets, Hibernate will create duplicate GroupSets and it results in database integrity issue when importing.
We manually corrected the data and ensured one to one mapping between them to proceed further. When do we plan to have the many-to-many mapping between Group and GroupSet?
We excluded these metadata types from the export.json to continue further. We are unable to import these in 2.25 also. Please do inform us once the fix is done in 2.25 so that we can retest.
When we update a new DHIS war, the instance is migrated to new DHIS version. But if existing data in our instance does not abide by the new constraints, the new constraints are not applied in our upgraded instance. So effectively it is not pure DHIS upgrade. So ideally, before applying the war file we should modify our data to abide the new constraints. Is this a right assumption?
Recently we did a DHIS upgrade test to upgrade our instances from 2.21 to 2.24. We started with 2.21 instance having good amount of metadata. We sequentially upgraded that instance to 2.24 by following the upgrade scripts for each DHIS version.
From that upgraded instance, an export was taken using the new exporter (/api/24/metadata). It was then imported to another fresh instance on 2.24 using the new importer. Below are our findings.
Most of the blockers were due to introducing of new constraints across DHIS versions. The upgraded instance did not have these constraints but the new fresh instance had them so it was preventing the import.
ex: shortName in dataelements table became unique
numerator is required for all indicators
dataelement_operand_unique_key (it is removed now)
We manually corrected our data so it abides as per the constraints. The list of constraints introduced in a DHIS version would be part of upgrade notes. Is this a right assumption?
Allow for many-to-many between Group and GroupSet. If we have groups which are part of multiple group sets, Hibernate will create duplicate GroupSets and it results in database integrity issue when importing.
We manually corrected the data and ensured one to one mapping between them to proceed further. When do we plan to have the many-to-many mapping between Group and GroupSet?
We excluded these metadata types from the export.json to continue further. We are unable to import these in 2.25 also. Please do inform us once the fix is done in 2.25 so that we can retest.
When we update a new DHIS war, the instance is migrated to new DHIS version. But if existing data in our instance does not abide by the new constraints, the new constraints are not applied in our upgraded instance. So effectively it is not pure DHIS upgrade. So ideally, before applying the war file we should modify our data to abide the new constraints. Is this a right assumption?
I’m currently looking into the import issues (from the other email also), will try and reproduce and will let you know if I need more information from you.
Recently we did a DHIS upgrade test to upgrade our instances from 2.21 to 2.24. We started with 2.21 instance having good amount of metadata. We sequentially upgraded that instance to 2.24 by following the upgrade scripts for each DHIS version.
From that upgraded instance, an export was taken using the new exporter (/api/24/metadata). It was then imported to another fresh instance on 2.24 using the new importer. Below are our findings.
Most of the blockers were due to introducing of new constraints across DHIS versions. The upgraded instance did not have these constraints but the new fresh instance had them so it was preventing the import.
ex: shortName in dataelements table became unique
numerator is required for all indicators
dataelement_operand_unique_key (it is removed now)
We manually corrected our data so it abides as per the constraints. The list of constraints introduced in a DHIS version would be part of upgrade notes. Is this a right assumption?
Allow for many-to-many between Group and GroupSet. If we have groups which are part of multiple group sets, Hibernate will create duplicate GroupSets and it results in database integrity issue when importing.
We manually corrected the data and ensured one to one mapping between them to proceed further. When do we plan to have the many-to-many mapping between Group and GroupSet?
We excluded these metadata types from the export.json to continue further. We are unable to import these in 2.25 also. Please do inform us once the fix is done in 2.25 so that we can retest.
When we update a new DHIS war, the instance is migrated to new DHIS version. But if existing data in our instance does not abide by the new constraints, the new constraints are not applied in our upgraded instance. So effectively it is not pure DHIS upgrade. So ideally, before applying the war file we should modify our data to abide the new constraints. Is this a right assumption?
