honeymoose
/
hapi-fhir
mirror of https://github.com/hapifhir/hapi-fhir.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

disabled old migration step that fails on fresh mssql db (#5841)

This commit is contained in:
Emre Dincturk 2024-04-11 15:50:04 -04:00 committed by GitHub
parent 4d8427ad60
commit 6e5c6fa33c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 17 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/migrate/tasks/HapiFhirJpaMigrationTasks.java
View File

@ -127,7 +127,7 @@ public class HapiFhirJpaMigrationTasks extends BaseMigrationTasks<VersionEnum> {
Builder version = forVersion(VersionEnum.V7_2_0);
// allow null codes in concept map targets
// allow null codes in concept map targets (see comment on "20190722.27" if you are going to change this)
version.onTable("TRM_CONCEPT_MAP_GRP_ELM_TGT")
.modifyColumn("20240327.1", "TARGET_CODE")
.nullable()
@ -2489,10 +2489,26 @@ public class HapiFhirJpaMigrationTasks extends BaseMigrationTasks<VersionEnum> {
.modifyColumn("20190722.26", "SYSTEM_VERSION")
.nullable()
.withType(ColumnTypeEnum.STRING, 200);
/*
DISABLED THIS STEP (20190722.27) ON PURPOSE BECAUSE IT STARTED CAUSING FAILURES ON MSSQL FOR A FRESH DB.
I left it here for historical purposes.
The reason for the failure is as follows. The TARGET_CODE column was originally 'not nullable' when it was
first introduced. And in 7_2_0, it is being changed to a nullable column (see 20240327.1 in init720()).
Starting with 7_2_0, on a fresh db, we create the table with nullable TARGET_CODE (as it is made nullable now).
Since we run all migration steps on fresh db, this step will try to convert the column which is created as nullable
to not nullable (which will then need to be coverted back to nullable in 7_2_0 migration).
Changing a nullable column to not nullable is not allowed in
MSSQL if there is an index on the column, which is the case here, as there is IDX_CNCPT_MP_GRP_ELM_TGT_CD
on this column. Since init720() has the right migration
step, where the column is set to nullable and has the right type and length, this statement is also
not necessary anymore even for not fresh dbs.
version.onTable("TRM_CONCEPT_MAP_GRP_ELM_TGT")
.modifyColumn("20190722.27", "TARGET_CODE")
.nonNullable()
.withType(ColumnTypeEnum.STRING, 500);
*/
version.onTable("TRM_CONCEPT_MAP_GRP_ELM_TGT")
.modifyColumn("20190722.28", "VALUESET_URL")
.nullable()