We wanted to automate updating concept index during OpenMRS startup.
I see that there is check on startup to test if “search.indexVersion” is not 3 to update the index. Is changing this global property the right way to trigger an update on startup?
This is the way that CIEL does it when we import the dictionary.
We have migrations outside the omod that adds concepts. It would be ideal to run the lucene index update on OpenMRS startup. The solution we are thinking of is to change “search.indexVersion” to 4 in the Activator class of one of the omods. So this would invoke the lucene index update on OpenMRS startup. Wanted to check if there was a better way to do this.
Just set “search.indexVersion” to an empty string. That should be all.
If the volume of concepts you add is low, wouldn’t be more optimal to update the index incrementally (after each concept added) instead of updating the whole index?
I just realised that startAndWait rebuilds the index altogether. Is there a way to do an incremental update?
p.s. Yet to look up the documentation
@shruthidipali, yes, there’s a way to update incrementally by calling Context.updateSearchIndexForObject for any concept you added/modified.
On the other hand rebuilding the whole index is not a big deal either as it’s pretty fast and takes just a few seconds for ~50k concepts.
@raff updating at the object level might not work because we add concepts through migrations/sql etc.
Context.updateSearchIndex uses MassIndexer.startAndWait. Can we introduce another method to use MassIndexer.start so the indexing can happen in the background and this does not slow down the app startup?
@shruthidipali, you could use start to run mass indexer in background. In such a case you would need to watch out for queries (e.g. by some module’s activator) against the index when the index is still being rebuilt, because results will be incomplete. We played it safe in openmrs-core and wait…