[wait until 0.4.21] Disable UpdateHistory for SV and Splitwell apps #2675
Conversation
[ci] Signed-off-by: Oriol Muñoz <[email protected]>
Signed-off-by: Oriol Muñoz <[email protected]>
| scanConnection <- createScanConnection() | ||
| recordTimeRangeO <- scanConnection | ||
| .getMigrationInfo(migrationId) |
There was a problem hiding this comment.
pay attention to this change
Signed-off-by: Oriol Muñoz <[email protected]>
Signed-off-by: Oriol Muñoz <[email protected]>
Signed-off-by: Oriol Muñoz <[email protected]>
Signed-off-by: Oriol Muñoz <[email protected]>
Signed-off-by: Oriol Muñoz <[email protected]>
OriolMunoz-da
changed the title
Signed-off-by: Oriol Muñoz <[email protected]>
| from update_history_descriptors; | ||
|
|
||
| IF descriptors = '{"DbSvDsoStore", "DbSvSvStore"}' THEN | ||
| RAISE NOTICE 'Truncating update history tables as only SV app descriptors are present. Descriptors: %', descriptors::text; |
There was a problem hiding this comment.
fun fact, flyway logs these, very useful!
| select array_agg(store_name order by store_name) into descriptors | ||
| from update_history_descriptors; | ||
|
|
||
| IF descriptors = '{"DbSvDsoStore", "DbSvSvStore"}' THEN |
There was a problem hiding this comment.
This is more strict than it needs to be - some of the descriptors in the update_history_descriptors might not be used by the tables that we want to truncate.
Also, in case someone has a very stupid production setup where multiple apps write into the same database, this will fail to delete the unused data.
I still think it's fine as is, in real setups it should work and worst case it just leaves around unused data.
| select array_agg(store_name order by store_name) into descriptors | ||
| from update_history_descriptors; | ||
|
|
||
| IF descriptors = '{"DbSvDsoStore", "DbSvSvStore"}' THEN |
There was a problem hiding this comment.
This is more strict than it needs to be - some of the descriptors in the update_history_descriptors might not be used by the tables that we want to truncate.
Also, in case someone has a very stupid production setup where multiple apps write into the same database, this will fail to delete the unused data.
I still think it's fine as is, in real setups it should work and worst case it just leaves around unused data.
| EXECUTE 'TRUNCATE TABLE update_history_assignments CASCADE'; | ||
| EXECUTE 'TRUNCATE TABLE update_history_unassignments CASCADE'; | ||
| EXECUTE 'TRUNCATE TABLE update_history_backfilling CASCADE'; | ||
| EXECUTE 'TRUNCATE TABLE update_history_creates CASCADE'; |
There was a problem hiding this comment.
Note to self: The acs_snapshot_data table has a foreign key constraint to update_history_creates. We don't need to truncate acs_snapshot_data because the SV app doesn't write any data into it (and we'd rather fail if there is any unexpected data in there after all).
| migrationInfo, | ||
| participantId, | ||
| ) | ||
| // splitwell does not need to have UpdateHistory |
There was a problem hiding this comment.
Do we need to truncate any splitwell tables as well?
|
|
||
| // Similar to PublishScanConfigTrigger, this class creates its own scan connection | ||
| // on demand, because scan might not be available at application startup. | ||
| private def createScanConnection()(implicit |
There was a problem hiding this comment.
The code is duplicated in HttpSvAdminHandler. Consider moving this to some helper/trait.
| participantId, | ||
| ) | ||
|
|
||
| val updateHistory = new UpdateHistory( |
There was a problem hiding this comment.
Do we have any tests that cover the update history of external parties?
2 participants
Fixes #1572
This PR removes the UpdateHistory from:
Includes also: