FHIR Chat · 3.4->3.8 JPA migration · hapi

Stream: hapi

Topic: 3.4->3.8 JPA migration

view this post on Zulip Seth Rylan Gainey (Sep 30 2019 at 13:41):

We're preparing a HAPI 3.4 to 3.8 JPA database migration, and a I have a few questions.

  1. Running the HAPI CLI with migrate-database -x no-migrate-350-hashes -d ORACLE_12C -f V3_4_0 -t V3_8_0 will upgrade the JPA schema to 3.6, but is missing columns expected in 3.7+ 
Schema-validation: missing column [REINDEX_COUNT] in table [HFJ_RES_REINDEX_JOB]
Schema-validation: missing column [SEARCH_DELETED] in table [HFJ_SEARCH]
Schema-validation: missing column [SEARCH_PARAM_MAP] in table [HFJ_SEARCH]
Schema-validation: missing column [HASH_IDENTITY] in table [HFJ_SPIDX_STRING]
Schema-validation: missing column [PARENT_PIDS] in table [TRM_CONCEPT]
Schema-validation: missing column [CS_VER_PID] in table [TRM_CONCEPT_DESIG]
Schema-validation: missing column [CS_VER_PID] in table [TRM_CONCEPT_PROPERTY]
Schema-validation: missing sequence [SEQ_RES_REINDEX_JOB]

Is this simply a gap in the migrator tasks? If so, we can add a PR to fix it.

2) What is the purpose of CalculateHashesTask run on the second pass without -x no-migrate-350-hashes? As far as I can tell, there should be a hash value for for all resources after mark-all-resources-for-reindexing.

view this post on Zulip James Agnew (Sep 30 2019 at 19:13):

  1. That does sound like a gap. We do have a unit test that should catch any such deficiencies at this point, but it only came into effect as of the 3.7.0 release. PRs welcome for sure..

  2. The second pass is basically just a failsafe check, to ensure that no hashes were missed anywhere in the process. If you confirm that none are missing anywhere, you can skip it.

view this post on Zulip Seth Rylan Gainey (Oct 01 2019 at 01:04):

Thanks, that makes sense. Another line of questioning regarding the reindexing process. We run HAPI in a k8s cluster with scaled deployments; is it safe for multiple JPA servers to run against a single database during reindexing? If the JPA server crashes/restarts during reindexing, will it pick up where it left off? My read of the code is that it the reindex will run on the API server it was called on, and that it should restart reindexing after calling $perform-reindexing-pass.

view this post on Zulip James Agnew (Oct 01 2019 at 19:49):

On a clustered server you need to ensure that scheduled tasks are disabled via the DaoConfig on all but one of the nodes- Otherwise all nodes in your cluster will try to reindex and you'll have pretty big problems.

That caveat aside, yes, it's completely safe.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -