Stream: hapi
Topic: Database migration from 4.1.0 to 5.2.0 Issues
Joe Atterberry (Jan 08 2021 at 22:43):
We’re leveraging the Migrator in the hapi-fhir-jpaserver-migrate project to migrate a HAPI FHIR version 4.1.0 database to a 5.2.0 database. There are a few tasks that need to be skipped in order to complete the conversion successfully. We made no modifications to the 4.1.0 schema. It looks to be related to dropping constraints. In all the cases the original constraint (create unique index …) was mapping to one or a set of columns on the table. The new constraint of the same name added a column or columns.
For us, the following tasks had to be skipped:
5_1_0.20200910.2
5_1_0.20200923.3
5_1_0.20201028.2
Any insights would be appreciated.
Thanks.
Jens Villadsen (Jan 09 2021 at 07:54):
@James Agnew
James Agnew (Jan 09 2021 at 18:36):
Hmm, these are all tasks that drop indexes and as you point out it's mostly just because new indexes will be created with additional columns.
Why did you have to skip them? Can you just manually drop the unwanted indexes?
Joe Atterberry (Jan 10 2021 at 00:57):
If I don't skip them, I get a non existent index error even though the index is there. I'm on a Mac using Oracle XE in a Docker container. It's pretty repeatable. I just start up the jpa server and allow the database to be created. I run the migrator and I get the following for the first constraint:
Caused by: org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [ALTER TABLE TRM_CONCEPT_MAP DROP CONSTRAINT IDX_CONCEPT_MAP_URL]; SQL state [72000]; error code [2443]; ORA-02443: Cannot drop constraint - nonexistent constraint
; nested exception is java.sql.SQLException: ORA-02443: Cannot drop constraint - nonexistent constraint
Joe Atterberry (Jan 13 2021 at 15:36):
Update: This now looks like a database issue.
I had two schemas in the Oracle XE instance with the identical structure as generated by starting up the JPA server. My plan was to leave one schema as is and use the other to apply the migration and then do some comparisons. The first schema was always there when I introduced the second identical schema and the migration on the second always failed. Once I removed the second identical schema and applied the migration to the first schema it worked fine. I have now created two instances of Oracle XE and will do the comparisons that way.
Last updated: Apr 12 2022 at 19:14 UTC
