Stream: hapi
Topic: name search after hapi upgrade 3.7 -> 3.8
Patrick Werner (Aug 05 2019 at 09:22):
Just upgraded our hapi installation to 3.8 from 3.7 and hapi stopped searching for names.
If i search for a Patient with Patient?name=foo, hapi can't find any patients. However if a create a new Patient searching for names works.
Any idea which kind of index i have to reset?
James Agnew (Aug 05 2019 at 19:05):
Did you run the database migrator command during the upgrade? If not, you probably need to do that..
Patrick Werner (Aug 05 2019 at 19:06):
i did. it showed that there is no needed update
Patrick Werner (Aug 05 2019 at 19:09):
i'm not sure if our server was updated from 3.5 -> 3.7 before .But in 3.7 everything worked. Do you think by upgrading to 3.8 now, something got triggered which didn't showed in 3.7? If so, is it safe to run a migration e.g. from 3.4 - 3.8 just to be sure? or can this cause problems?
James Agnew (Aug 05 2019 at 19:42):
Yup, it's always safe to run the migrator from older versions, it'll only make changes that are needed.
Can you check your HFJ_SPIDX_STRING table to see if there are any null values in the HASH_IDENTITY column? If so, that's the issue. This column was added in 3.6 but we only switched to using it in 3.8 so if you did a 3.5->3.x migration without running the migrator that's almost certainly the issue.
Patrick Werner (Aug 05 2019 at 21:05):
thanks a lot. I think that caused the issue. Running the migration tool didn't change anything (i think because the index was already created through the first start of 3.7 or 3.8 ? So the script assumes "nothing to do there"?
To prevent such issues, did you ever discuss using liquibase to automatically upgrade DB schema if needed?
James Agnew (Aug 06 2019 at 01:24):
Yeah, it may be identifying that nothing is needed since some of the indexes have been built already. You could force the indexes to be rebuilt by invoking the $mark-all-resources-for-reindexing operation at the root of the server).
We looked at liquibase and flyway, but ultimately wanted something more flexible (and we suffer a bit from not-inveted-here syndrome :) ). The intent with the migrator tool is definitely that it will be able to run automatically in the future when configured to do so. We're almost there.
Patrick Werner (Aug 06 2019 at 12:35):
great news. And thanks, reindexing solved all our problems
James Agnew (Aug 06 2019 at 13:40):
woohoo! man, we really need to automate that
Last updated: Apr 12 2022 at 19:14 UTC
