I am looking for a best practice to enable the running of activator code under the following circumstances:
When the module has a SNAPSHOT version (its still in development)
When a module version changes - where are module versions stored in the recent versions of OpenMRS?
This will improve the performance of our implementation at startup as it runs through saving global properties, forms, etc which have not changed
Looks like the Initializer approach would suit your requirement. The Initializer only processes configuration files that have changed, this is based on their md5 checksum.
Global properties are already handled, example here. Forms aren’t yet, but of course this could become the subject of new domain (named ‘hfe’ for example).
@mksd an interesting one - how to use Metadata descriptors as XML files instead of MDS zip packages just like the global properties
If you mean something that can be deserialized right away, yes we have already taken that route for some domains such as ‘idgen’.
However the preferred approach is to provide metadata (or even data in some cases) through CSV files. And each new CSV would require to implement an ad-hoc line processor extending BaseLineProcessor.
We allow the drop-in of MDS packages because it was an easy, quick and convenient way to bring in metadata, but an XML or preferably CSV parser should always be favored.
We are trying to make the so-called ‘openmrs configs’ such as this one manageable by implementors, and that is why we promote the CSV use case.
@mksd Thanks for the clarification, let me think through how to leverage CSV for available metadata descriptors, and I will get back to you.