Error creating patient for large location IDs.

Tags: #<Tag:0x00007f302bfac2d0>

OpenMRS Version: 1.9.2

Question: Hi Everyone,

I am newbie here… posting for the first time in OpenMRS talk. The issue which I’m facing is when I am trying to create a patient in OpenMRS (version 1.9.2), I get the following error message.

As according to this part of the error below, it seems that the location ID of values greater than 1000 are being converted to string. And I have tried this for several location IDs greater than 1000… same error occurs each time.

Any suggestions on this would be highly appreciated. If this issue still persists in OpenMRS, shall I create a ticket for this?

Many thanks…

Do you know how the number has a comma in it? I have never seen that happen before. Is it done custom code of yours?

E.g. instead is 1,440 it should be 1440.

Dear Darius,

That is what I’m unable to figure out that why is it converting it to string… No, it is not customized code. I’m creating a patient from OpenMRS from the ‘Create Patient’ link. Any insight into this would be highly appreciated, as it is blocking our project to function properly. Thanks

Are you able to reproduce this on OpenMRS versions 1.9.9?

This issue can’t be observed unless we have over 1000 locations in the system, which probably doesn’t happen for most of the OpenMRS installations.

Tahira, can you please try to reproduce on 1.9.9, as Daniel suggested?

If you do not have those many locations, just create one new location, go to the database and change its id to that value.

Another question, does it work well if you choose one that has a location of a lower id?

It works for locations lower than 1000. I’ll try to reproduce this error on OpenMRS 1.9.9.

While testing on 1.9.9 still remains, I was able to reproduce the same on 1.11.4. You can just execute “alter table location auto_increment = 1000” to quicken the process.

Just confirmed. Adding the following test to LocationEditorTest fails the test:

@Test
public void setAsText_shouldSetUsingIdWithGrouping() throws Exception {
	LocationEditor editor = new LocationEditor();
	editor.setAsText("1,000");
	Assert.assertNotNull(editor.getValue());
}

I think this issue should be ticketed. I’m wondering if any of the OpenMRS implementations have registered more than 1000 locations before.

Ofcourse that should fail because you are supplying an invalid location id that has a comma. So the LocationEditor is behaving correctly as expected. :slight_smile: Simply as the value of 10 but with a comma, would also fail. editor.setAsText(“1,0”);

1 Like

Oops! Okay, I corrected this and the test still fails. :innocent:

What does the test now look like? And what is the failure stack trace?

Hi,

I tried to reproduce it on OpenMRS 1.9.9, and same error occurred for location ID: 1000. So, I’ll be creating a ticket for this.

public void setAsText_shouldSetUsingIdWithGrouping() throws Exception {
	LocationEditor editor = new LocationEditor();
	editor.setAsText("1,0");
	Assert.assertNotNull(editor.getValue());
}

And the stack trace says:

ERROR - LocationEditor.setAsText(60) |2015-10-15 14:10:52,591| Error setting text: 1,0
java.lang.NumberFormatException: For input string: "1,0"
	at java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.lang.Integer.parseInt(Unknown Source)
	at java.lang.Integer.parseInt(Unknown Source)
	at org.openmrs.propertyeditor.LocationEditor.setAsText(LocationEditor.java:53)
	at org.openmrs.propertyeditor.LocationEditorTest.setAsText_shouldSetUsingIdWithGrouping(LocationEditorTest.java:27)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

I’ve found a fix though. Parsing the text using DecimalFormat object with number grouping flag disabled will handle the number formatted in group. However, it is peculiar that the webpage is converting this into grouped format.

I was also able to reproduce this for all ids that have four digits. The problem seems to come from shotPatientForm.jsp at:

form:options items="${locations}" itemValue="locationId" itemLabel="name"

So go ahead and create a ticket.

Here’s the ticket

1 Like

Another work around for this issue is to click “Add Identifier” to add a new row and delete the first one. The newly added identifier won’t have this issue.