Details
-
Bug
-
Status: Closed (View Workflow)
-
TBD
-
Resolution: Done
-
None
-
None
-
CP: sprint 137
-
1
-
Core: Platform
-
TBD
Description
Consider this table definition in schema.json:
{ "tableName": "job_execution_progress", "fromModuleVersion": "mod-source-record-manager-3.3.0", "withMetadata": false, "mode": "delete", "foreignKeys": [ { "fieldName": "jobExecutionId", "targetTable": "job_executions", "tOps": "DELETE" } ] },
The current RMB code executes
ALTER TABLE diku_mod_source_record_manager.job_execution_progress DROP COLUMN IF EXISTS jobExecutionId CASCADE; DROP TRIGGER IF EXISTS update_job_execution_progress_references ON diku_mod_source_record_manager.job_execution_progress CASCADE;
This fails if the table has been deleted.
Solution: Don't install/update indexes, foreign keys and optimistic locking (OL) when the table has "mode": "delete".
TestRail: Results
Attachments
Issue Links
- relates to
-
RMB-818 Migrations: delete tables after update scripts
-
- Open
-