I’ve noticed some peculiar behavior regarding the getAllObs method on encounter. I would assume that it would fetch a flattened list of all the obs associated with the encounter but however that is not exactly what the method returns… it only returns obs that have been directly linked to the encounter, which may or may not be the case for nested obs. Some tests seem to suggest that this is expected behavior, for instance, see:
In practice, it looks like the connection between the nested obs and the encounter is only made at the time that the encounter is flushed to the database. Take a look a this test from REST web services, which creates an encounter with nested obs and then fetches the encounter back, expecting the size of getAllObs to be 1 (ie only the top-level obs):
If I change this test so that it does a Context.flushSession() and Context.closeSession() after the Encounter is posted but before the Encounter is reloaded, this assertion will start to fail as getAllObs().size will now be 3!
Besides being inconsistent, this seems problematic, because the getAllObs method is used by the EncounterService to update the obs associated with an encounter and to copy all obs from one encounter to another. It seems like this in practice this will only work if we are dealing with an object that has been persisted to the DB?
(The actual bug we are seeing is that if you try to update a encounter via REST and change the encounter datetime, that change is only propagated to the obs datetime of the top level obs).
Should we create a new method that explicitly flattens and fetches all the Obs on an encounter? Should we change the behavior of the existing getAllObs method? I’d worry about backwards compatibility, so maybe we should create a new method with a clearer name, and then deprecate getAllObs?
Take care, Mark