Attributable Types

So I’ve been spending some time thinking about how to migrate OpenMRS towards a more micro-service like architecture, as was discussed with some enthusiasm in Maputo. One of the steps in making such a move more feasible, suggested to me by @angshuonline, is to make the OpenMRS data model an isolateable component, i.e., to be able to create a JAR of the various OpenMRS data objects that’s separate from the services, etc.

There are various reasons why this is challenging, but one of the more uniform ones is that every class that implements the Attributable interface has to implement two methods, one called findPossibleValues() and the other called getPossibleValues(), which return, respectively, all the values of type X that match a certain string and all the values of type X. These seem to be implemented in the most straight-forward way possible: get a reference to the relevant service, and use that to query the DB. The problem is that the obvious way to do this is this (taken from

public List<Concept> getPossibleValues() {
    try {
        return Context.getConceptService().getConceptsByName("");
    catch (Exception e) {
        // pass
    return Collections.emptyList();

The problem is that this adds a hard dependency on Context, which itself has a dependency on the pretty much the entire service layer in core.

When I search through the code in the OpenMRS Github organisation, there are many implementations of getPossibleValues(), but no code that seems to use this method and the only code I can find that uses findPossibleValues() is a unit test for the Concept class.

Given all that and the fact that the functionality implemented by these methods is easily replaceable, I wondering whether it might be a good idea to just deprecate and / or remove these methods. Any thoughts or comments?

NB: Putting micro services aside, i also do not like this dependency.

There are a number of other data model classes that add a hard dependency on Context for other unrelated use cases. Is this the first step towards getting to all of them? :slight_smile:

Yes, hopefully! This is just really low-hanging fruit towards that goal.

Given the fact that this interface has been around for 13 years without any meaningful use of those two methods,, i would vote with a YES to deprecating and eventually removing them. :smile: