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]
