Do you know which method in the interceptor is called on that first save? Is the dateChanged set at the end of the transaction? If you flush the session right before your failing assert, does the assert then pass?
Ben On Thu, Nov 24, 2011 at 12:22 AM, Mark Goodrich <[email protected]> wrote: > Sorry I missed the design call on hibernate interceptors today, but, > coincidentally, I was investigating an issue with the Auditable interceptor > that I uncovered when running the HFE unit tests against 1.8. Or, rather, > something that may be an issue. > > Take the following unit test, which creates a new encounter, saves it, > updates the obs associated with it, and saves it again. Using the old save > handlers, the dateChanged of the encounter would be set upon the second > save. But, with the hibernate interceptor, this is not the case and so > this test will fail: > > public void editingNewEncounter_shouldUpdateDateCreated() throws Exception > { > EncounterService es = Context.getEncounterService(); > > // First, create a new Encounter > Encounter enc = new Encounter(); > enc.setLocation(new Location(1)); > enc.setEncounterType(new EncounterType(1)); > enc.setEncounterDatetime(new Date()); > enc.setPatient(new Patient(3)); > enc.setProvider(new Person(1)); > > // Now add a couple obs to it > Obs newObs = new Obs(); > newObs.setConcept(new Concept(1)); > newObs.setValueNumeric(50d); > enc.addObs(newObs); > > Obs anotherNewObs = new Obs(); > anotherNewObs.setConcept(new Concept(1)); > anotherNewObs.setValueNumeric(100d); > enc.addObs(anotherNewObs); > > // now save the encounter > es.saveEncounter(enc); > > // flush the session, just to be safe > Context.flushSession(); > > // confirm that the encounter has been assigned an id, but > the date changed is still null > assertNotNull(enc.getId()); > assertNull(enc.getDateChanged()); > > // confirm tha the obs have been added to the encounter > assertEquals(2, enc.getAllObs().size()); > > // Now edit the obs and resave the encounter > for (Obs o : enc.getAllObs()) { > o.setValueNumeric(75d); > } > > // resave the encounter > es.saveEncounter(enc); > > // FAILS: confirm that the date changed has been set > assertNotNull(enc.getDateChanged()); > } > > Note, however, that if I load an existing encounter and update the obs, > the date changed will be set: > > public void editingExistingEncounter_shouldUpdateDateCreated() throws > Exception { > EncounterService es = Context.getEncounterService(); > > // First, load an existing Encounter > Encounter enc = > Context.getEncounterService().getEncounter(3); > > // confirm that the date changed is null > assertNull(enc.getDateChanged()); > > // Now edit the obs and resave the encounter > for (Obs o : enc.getAllObs()) { > o.setValueNumeric(75d); > } > > // resave the encounter > es.saveEncounter(enc); > > // PASSES: confirm that the date changed has been set > assertNotNull(enc.getDateChanged()); > } > > In the first case the encounter is never passed to the interceptor > onDirtyFlush method... I would assume because the Encounter is still in > the new/save state? Is this a problem? This is a contrived case, and it > seems to make sense that if an encounter is saved twice in rapid succession > it's date changed isn't set--but this isn't the behavior I would have > expected, and it is different from how the old save handlers worked. > > Thoughts? > Mark > > > > _________________________________________ > > 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] > _________________________________________ 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]
