If (1) we are recording the same dateVoided for all data voided in a single transaction (i.e., even if the voiding takes several seconds) and (2) dateVoided is recorded in seconds or milliseconds, then I don't think we need to require that the voidReason match, since it leaves open the option to make voidReason appropriate to the object (e.g., we *could* set the voidReason for obs with "encounter voided" even though the encounter gets a voidReason of "invalid encounter"). I'm not saying that we need to change things if we're using the same voidReason across all objects voided in a single transaction; rather, I'm saying that we don't necessarily need to * require* the same voidReason across all objects if the voidDate is unique enough to make the likelihood of duplicate voidDates for the same patient vanishingly small.
-Burke On Fri, Sep 9, 2011 at 11:54 PM, Darius Jazayeri <[email protected]>wrote: > FWIW, it looks like the unit test in question is bad, in that it's > sensitive to the clock time, so putting a Thread.sleep(100) in the middle of > the test fixes it. > > But looking at the code I realized that we're not doing things exactly > right. Currently, when you unvoid a patient, it also unvoids any of their > encounters and orders with the same voidedBy and dateVoided. But we're not > looking for the same voidReason. Any reason we shouldn't be looking at that > too? > > -Darius > > > On Fri, Sep 9, 2011 at 8:27 PM, Darius Jazayeri <[email protected]>wrote: > >> So, it looks like the specific problem I was running into is that I was >> using a workspace folder under one of the parallels-mapped network drives >> (\\psf\...) and one of Eclipse/Maven/Java/WinXP didn't like that. So after >> switching to c:\workspace, I was able to get the build to run. >> >> Of course then I hit a unit test failure, which happens on this windows >> VM, but not on the up-to-date checkout I have on my regular OSX install... >> >> PatientDataUnvoidHandlerTest >> org.openmrs.api.handler.PatientDataUnvoidHandlerTest >> >> handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(org.openmrs.api.handler.PatientDataUnvoidHandlerTest) >> java.lang.AssertionError: >> at org.junit.Assert.fail(Assert.java:91) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at org.junit.Assert.assertTrue(Assert.java:54) >> at >> org.openmrs.api.handler.PatientDataUnvoidHandlerTest.handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(PatientDataUnvoidHandlerTest.java:134) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) >> at >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >> at >> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) >> at >> org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) >> at >> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) >> 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:193) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) >> at >> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) >> at >> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) >> at >> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) >> 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:467) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) >> >> -Darius >> >> _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
