referenceapplication 2.5 is not compatible with iSantePlus module we developped with referenceapplication 2.3

@craigappl, as @darius mentions, this is likely an issue from the core platform version - between refapp 2.3 and 2.5, core was upgraded from 1.11.4 to 2.0.1. So I’d look at what changed there first, in terms of looking up concepts by mapping.

@darius, I agree with fixing it there, but for all of the implementations that are not going to be on platform 2.1 in the near future, making a (relatively minor) improvement to htmlformentry still probably makes sense. No reason not to do both…


Just read this over quickly and haven’t looked at the code yet, but are we saying that form loading time jumped from around 3.5 second to 120 seconds after an upgrade from 1.11.4 to 2.0.1? Regardless of long-term fixes, wouldn’t that suggest that a gross inefficiency in getConceptByMapping was introduced at some point and should be fixed (and backported)? (Or are we saying that assumedly the slowdown was caused by the conceptual change to using Lucerne, which we won’t want to revert, but will only be able improve going forward in 2.1?)

Take care, Mark

I agree that if the same code runs 40x slower when going from platform 1.11 to 2.0 then we should treat that as a bug and address it.

So we have steps to reproduce this? (Sorry I’m also just skimming this thread.)

-Darius (by phone)

@craigappl can you confirm that what I stated above is accurate?

this seems like a likely culprit, I suspect it negates any benefits that indexing may be having:

Oh, and, yes, to answer your earlier question @craigappl, using a source/mapping pair in the concept ID (over straight concept ID or uuid) would be considered best practice. (Another reason we should fix the bug that is making this so slow).



I’m going to setup two identical vms on my machine today with platform 1.11.x and 2.0.4. What’s the best way to replicate this environment so others can evaluate it? Are there any dev/test instances available online with OpenMRS 1.11.x?

Thanks, Craig

I’ve created a new ticket for what I think is the issue:

@craigappl do you have any dev capacity available? If so, if you could build a custom openmrs.war with the change made in TRUNK-4452 reverted and see if it fixes the performance problem you were seeing. If it does, you’ll have a pretty strong case for flagging TRUNK-5071 as a priority ticket to fix and backport.


Thanks Mark!

Yes, I’ll build the war and test it out. I’ll likely have to get to this tomorrow. I’ll make sure to document the steps in the ticket.

Thanks, Craig

It’s faster when I build a custom openmrs.war with the change made in TRUNK-4452 reverted

@guerschon back to only a few seconds to load vs 120 seconds?

Yes, back to only a few seconds

Alright, thanks! I’ve commented about that on TRUNK-5071, but feel free to add your own comments there as well.


I don’t know if this is still relevant, but the typical way to do this would be to create an file that someone else can then open via the SDK. (You’d probably need to share a SQL file too.)

@guerschon @craigappl turned out there is a global property that may be able to allow you to work around this issue.

Can you try setting the global property “search.caseSensitiveDatabaseStringComparison” to false, and see if that fixes your issue?

Take care, Mark

@mogoodrich & @guerschon

I confirm that setting that property to false fixed the issue.

@darius, @mogoodrich, @mseaton Should we set that to false in the default OpenMRS Platform global property configuration or should we set it to false in our module? If in OpenMRS platform, I can create a PR.

Thanks, Craig

@craigappl, I would set it in your module. If we think it should default to false in the platform, we can get consensus and ticket it, but I would just set it in your module and not wait on that dependency.


@k.joseph Dear Kaweesi, As you already know we are upgrading from OpenMrs 1.11.5 to OpenMrs 2.0.5. While doing so we are facing certain difficulties. Thank you for Helping with the first batch of initial problems. But now we are facing the following issues: • The form history doesn’t display back the previous entered data correctly (There are no logs for that problem that we can find) • Normally end users should not be able to enter a first visit form twice. That functionality was working fine on the old version, now it’s broken by allowing multiple entries. Please find the complete list of omods we are using for the current platform. We know that you are extremely busy but can you find some spare time to unblock us? The link to the Github branch :


FYI @k.joseph & @guerschon

I dug a bit deeper into the HTML form display issue and wonder if something has changed from htmlformentryui v1.3 to 1.4 and now 1.6.1. We have only changed the names of the html forms as we have been working through the upgrade.

The problem: When we save a form and then click on it to view it, none of the data is being displayed. I reviewed the database and it’s clear that the observations and encounters are stored properly. Additionally, the isanteplus_forms_history table is appropriately being created using the save advice.

Steps to reproduce:

  • I uploaded the latest build of the module to Google drive. You can download it and run it on OpenMRS 2.5.
  • You have to install the latest version of the CIEL dictionary for the forms to display.
  • Create a patient
  • Start a visit
  • Complete the Primary care form “primaire consultation” and save the form
  • Return to the forms history screen and click the form name in the forms history table
  • You’ll be redirected to the viewEncounter page and you see that no observations are showing up. (They do show up on the same form in htmlformentryui v1.3, but not in 1.4 or 1.6.1)


Thanks, Craig

Hi Again,

I think we figured out the problem. The obs with answerconceptIds="" are not displaying in the UI when you click viewEncounterWithHtmlForm. They also don’t display in the

For example: saves to the database, but doesn’t display in either of these pages.