@bharatak, after our Dev Forum on Platform 1.12 Release planning, I realized that we overlooked an important step in going from beta to official release for 1.12 – i.e., make sure basic functionality is preserved. For example, during the call, I discovered that concept searching is broken in the 1.12-beta standalone.
This problem appears to be deeper than the UI:
GET http://localhost:8081/openmrs-standalone/ws/rest/v1/concept/be472bc0-1691-11df-97a5-7038c432aabf
```bash
fetches SERUM CREATININE as expected; however,
```bash
GET http://localhost:8081/openmrs-standalone/ws/rest/v1/concept?q=serum
returns an empty set even though there are over a dozen concepts with “serum” in their name.
@maurya & @darius – what’s the recommended method for regression testing basic functionality? Do we still rely on manual testing or should something like this (simple concept search failure) be caught by integration tests?
Concept word is no longer used. The lucene index needs to be re-built. You can do this manually from the the Administration page. I agree with Burke that this should happen automatically, and if it is not happening automatically we need to fix this.
Looking at the instructions for building the standalone, they say nothing about rebuliding the lucene index. @maurya, can you ensure that the correct step here gets documented?
@burke, which option did you choose in the standalone? Demo data? Starter implementation?
We do not have any automated testing of the legacy UI, nor is there any automated testing of the built standalone artifacts. Ideally we would script the standalone build process, and run this in CI–then we could test the built artifact. For now, though, manual testing is all we have to ensure that the standalone is configured correctly (and that basic functionality hasn’t been lost).
Going to Administration > Maintenance > Search Index and clicking Rebuild Search Index did the trick.
If I were to create a ticket to automatically trigger indexing on first run, does that belong in core (trunk), platform, or just the standalone (i.e., where would the fix be needed)? It’s definitely needed in the standalone, but I could see triggering the index as one of the last steps of installation (initial run) that might apply beyond just the standalone.
I think it belongs in core. The reason I recognized this is because we hit the exact same problem last week on our Bahmni install, which doesn’t use the standalone. I think the issue is that any time concepts are installed with liquibase (or any direct sql), the concept search index needs to be re-built afterwards. I would assume adding concepts via the API handles this correctly already.
We in Bahmni did it as part of Bahmni OMOD to updateSearchIndex on Activator’s start up. This is the link for it. But I agree with @mseaton that it should belong to core and should be part of openmrs startup
My proposal is to rebuild the lucent indexes in core update filter after the database changes have been run here. See line 740 for code to run database updates.
The tricky thing is how to know when the indexing is done since it runs in parallel, you might want to keeping checking the value of the associated GP that gets set when the indexing is done, that way when it is set, you can assume the indexing is done.
However in TRUNK-4717 a simple call is made to Context.updateSearchIndex(), there is no indication of polling the GP.
What I am suggesting is placing the above method after platform is started in UpdateFilter and the database updates have been run. (I have tested this and it works.)
