Hello all…
I’m struggling a bit with coming up with the right approach to address an issue with trying to fetch a custom representation of an Encounter that have Obs with “value location” and was looking for suggestions.
The underlying issue may be that we were trying to get too “cute” and create a hacky way to support “value locations” for obs.
The History:
There’s a supported pattern where you can set the “comments” field of an obs to “org.openmrs.Location” and then set the the “valueText” field of that obs to the primary key of a location in the database.
The REST web services module supports this format and returns a Location object as a obs value in this case, see:
Current Issue:
In one of our OWAs, I’m trying to fetch an Encounter RESTfully using a custom representation. A simplifed version of the rep I’m using:
custom:(id,uuid,encounterDatetime,obs:(id,uuid,value:(id,uuid,display,names:(id,uuid,name,locale,localePreferred,voided,conceptNameType)),obsDateime))
So, when pulling back the the obs on an encounter, if one of the obs has a value of a “Location”, it fails when trying to convert a “Location” to this custom ref:
(id,uuid,display,names:(id,uuid,name,locale,localePreferred,voided,conceptNameType))
It’s not entirely clear to me what the best/correct solution for this is, as I feel we’ve exposed a limitation of have a “flexible” schema for obs value.
Note that in this case, I actually don’t care about the obs of type location, so I could create a custom endpoint that returns a subset of obs on the encounters, excluding the problematic ones. But I do feel like this is a problem that could turn up in other cases. (And also would be likely to fail silently and/or be missed by testing).
Some options:
-
Change the base REST web conversion handler so that if a custom rep throws an error when parsing, don’t fail entirely, but log an error and return the default (or reference?) representation of that particular sub-object. This would likely be the easiest option, but not sure it’s really correct and would broadly touch the REST web services conversion error handling
-
Do something similar to #1, but instead of adding it to the main conversion code, create a custom Location converter and only allow bad custom representation for Locations (and potentially only for those that are obs values… though I’m not sure if the parent element is available to the parser). This seems uglier than #1, but is also less intrusive.
-
Try to define some sort of custom rep format that allows for conditional refs based on object type. This seems potentially overkill and ugly and non-trivial and risks instability in the custom rep code:
value:(Concept|(id:uuid:names)|Location(id:uuid:name:tag))
Thoughts? Any potentially elegant solutions I’m missing?
@mksd @ibacher @dkayiwa @cioan @bistenes
Take care, Mark