am wondering why does the SearchHandler not depend on a Resource ?
Currently the SearchHandler.getSearchConfig returns the SearchConfig which contains the supportedResource which is simply a String.
So the same String for ex. “v1/obs” that has been declared on the Resource in the annotation is repeated again in the declaration of the SearchConfig.
So there is a dependency of SearchHandler to Resource just not in the code. If you write a SearchHandler for a Resource that doesn’t exist obviously that won’t work but you will only notice at runtime.
Am wondering why that is and If it should be changed?
Is the reason that a SearchHandler the way SearchConfig works now can support Resources for multiple OpenMRS versions?
So if we have for ex. Resource “v1/obs” spread across multiple files like ObsResource1_8 , ObsResource1_9, ObsResource1_11 for the different OpenMRS versions you can have one SearchHandler for them all.
This seems flexible in the sense that if only the Entity Obs changes in different Openmrs versions but the service API doesn’t you don’t have to change the SearchHandler and the other way round. Which is nice.
But still I feel like this repetition of strings of the resource uri “v1/obs” is not ideal. Mhmmm
I think that the point you raise in your second message is a pretty good reason to leave things as they are (so a SearchHandler can work across multiple resource classes).
@teleivo, yes, it’s the exact reasoning I followed when declaring the resource uri on the search handler rather than a specific resource class.
It allows to support multiple OpenMRS versions, see ConceptSearchHandler1_9.java, which supports ConceptResource1_9, ConceptResource1_11, ConceptResource2_0.
You could ask why not to specify all 3 classes on the search handler, but ConceptResource2_0 for instance is not even available on the classpath when running webservices.rest on OpenMRS 1.11.
There are many resources in Webservices rest, that are of BaseAttributeCrudResource type. (e.g. Location, Patient, Provider, Visit etc. Concept should also be so, since it supports attributes now). I was wondering if we should extend query by attribute, which will be extremely helpful for everyone.
Right now, this need to be done using a Custom Search Handler providing a custom SearchConfig.
Recently, I have done so for Provider, but was wondering if there should be a generic means of doing that!
I understand that there would need to more code added to “doSearch” method and also that the underlying service (e.g. ProviderService) should support means of fetching that. It can also be a case that such query maybe combined with other search parameters. E.g. fetch me all Providers matching name “X” but belong to Department (Attrubute) “Y”.
Thoughts? Or would you rather have such SearchHandler in specific implementation specific modules?
I think BaseAttributeCrudResource type refers only to the attribute types, not the base types themselves (ie LocationAttribute is a BaseAttributeCrudResource, while Location is not).
But that seems tangential to your question, for what it’s worth, I’d support the basic queries supporting searching by attributes… however, I think/suspect that the doSearch methods for the various metadata like Locatio, Provider, Visit, etc have already diverged enough so that it would be more work that just adding attribute support, but rather standardizing them?
