org.dbunit.dataset.NoSuchColumnException: PATIENT_IDENTIFIER_TYPE.CHECK_DIGIT after Openmrs 2.0 upgrade

Development
, ,
1

After upgrading to Openmrs 2.0, some of our tests started failing with the following error during data setup:

org.dbunit.dataset.NoSuchColumnException: PATIENT_IDENTIFIER_TYPE.CHECK_DIGIT -  (Non-uppercase input column: check_digit) in ColumnNameToIndexes cache map. Note that the map's column names are NOT case sensitive.
	
at org.dbunit.dataset.AbstractTableMetaData.getColumnIndex(AbstractTableMetaData.java:117)
	at org.dbunit.operation.AbstractOperation.getOperationMetaData(AbstractOperation.java:89)
	at org.dbunit.operation.RefreshOperation.execute(RefreshOperation.java:98)
	at org.openmrs.test.BaseContextSensitiveTest.executeDataSet(BaseContextSensitiveTest.java:775)
	at org.openmrs.test.BaseContextSensitiveTest.executeDataSet(BaseContextSensitiveTest.java:670)
	at org.bahmni.module.bahmnicore.web.v1_0.controller.BahmniPatientProfileResourceIT.setUp(BahmniPatientProfileResourceIT.java:53)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:73)
	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:73)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:217)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:83)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	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:68)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:163)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

Did anyone faced this issue before? Any help?

2

Found that the column has been removed in openmrs 2.0. Removed the column in datasetup and fixed the tests. Got confused since the variable is still present in PatientIdentifierType java model and some datasetup xmls in openmrs-core.

3

It’s possible that the knowledge of check digit existence was intended to move into a handler for an identifier type rather than being managed separately and this change was not fully implemented. @maany, @wyclif, @dkayiwa, or @raff: do you know the history here?

4

I’ve looked at the github history, and here is what I think happened:

In the early days of OpenMRS we used patient_identifier_type.check_digit column, but this functionality was moved into patient_identifier_type.validator long long ago (before we started using maven in 2010), but we didn’t completely remove this at the time…

  • We finally removed this from the hbm.xml file in the monster commit for TRUNK-4772 (Removing Deprecated methods), and this is why Bahmni tests started breaking when moving to openmrs-core 2.0.
  • We removed the getter and setter for the PatientIdentifierType.checkDigit property (in the Removing Deprecated Methods commit) but we forgot to remove the property itself.
  • We never removed the check_digit column from the data model.
    • There is a patient_identifier_type.check_digit column in the data model here, and it is never removed here.

So, @preethi_s, what you have done in the second message in this thread is the correct thing to do for Bahmni.

On the OpenMRS side, we should create a ticket to clean up the remaining vestiges of this old column/field.

1 Like