When we change an answer for a coded concept, it does not reflect in existing form, and requires us to create the next version of the form. Every-time a new version is published we also need to change groovy.
Ideally we do not want a user intervention every time we add or remove an existing answer.
In order to solve this, we want to propose a caching mechanism to store the concept answers and update the data on concept change event and forms read the data for answers from this cache.
Few things that we discussed in the PAT call
- in Form definition, introduce “load answers dynamically” attribute for the control. if yes, then the form engine would fetch the answers dynamically.
- Caching - try to leverage existing lucene indexes. IMHO, nothing to be done, other than using the correct search api - which I think it already does.
Do a comparison of performance before introducing any other infra (e.g. Redis!) , also leverage existing ehCache already available in OpenMRS.
- While loading answers - try to optimize fetch of “answers” for all such “concepts” in the form. Can we device a mechanism of getting all such answers in one call for all such concepts in the form (only for those which are marked to fetch answers dynamically).
Thanks for the summary @angshuonline.
We would also like to introduce caching of translations, similar to answers. Today when translations are generated they do not change after translations are changed in openmrs.
So, we can have one more attribute called “load translations dynamically”. if yes, then the form engine would fetch the translations dynamically.