Lucene indexing for concepts created through migrations

Lucene indexes are built if the value for global property search.indexVersion is different from OpenmrsConstatnts.SEARCH_INDEX_VERSION. However in Context.java in public synchronized static void startup(Properties props) by the time getContextDAO().setupSearchIndex() call is made, omods are not yet up. Any concept, that is created through a migration task in any of the omods, is not indexed. Is it the expected behaviour?

In Bahmni we create few concepts through migrations. So we will now have to rebuild indexes from UI. On productions dumps(with ~ 5 lakh patients) it takes 45 min to rebuild indexes. Indexing happens fine in the backend but as it takes 45 min, there is a time out issue which raises a false alarm saying “There was a problem rebuilding search index” on UI even though it is still indexing in the backend. So the users will have to randomly try searching concepts/patients to check if indexing is done.

Can you please suggest if there is a better way to get around this? @raff @dkayiwa @darius

I assume your migrations do not use Hibernate when creating new concepts rather access db directly, otherwise Hibernate should have updated the index for newly created concepts.

Did you consider calling https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/api/context/Context.java#L1308 for concepts you create through migrations?

I think the possible workarounds here are:

  1. Create the concept via the OpenMRS API instead of via a SQL stored procedure
  2. Just update the search index for the one object (like Rafal says)
  3. Update the search index for concepts, but not patients, using Context.updateSearchIndexForType()