Skip to content

Conversation

@OriolMunoz-da
Copy link
Contributor

@OriolMunoz-da OriolMunoz-da commented Oct 13, 2025

Fixes #1572

This PR removes the UpdateHistory from:

  • sv-app SvSvStore
  • sv-app SvDsoStore
  • SplitwellStore

Includes also:

  • Separate UpdateHistory from stores. The alternative seemed to involve cake pattern / visitor pattern / instance matching when registering the ingestion service. This seems way cleaner.
  • No more passing around Storage and throwing on every spot that can only work with DbStorage
  • No more Option[UpdateHistory] metrics, now that UpdateHistory is separate from stores
  • See also Make scanConfig mandatory in SV app #2686 for more annoyance

Comment on lines +93 to +95
scanConnection <- createScanConnection()
recordTimeRangeO <- scanConnection
.getMigrationInfo(migrationId)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]>
@OriolMunoz-da OriolMunoz-da marked this pull request as ready for review October 14, 2025 13:14
@OriolMunoz-da OriolMunoz-da changed the title Disable UpdateHistory for SV and Splitwell apps [wait until 0.4.21] Disable UpdateHistory for SV and Splitwell apps Oct 15, 2025
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;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fun fact, flyway logs these, very useful!

Image

select array_agg(store_name order by store_name) into descriptors
from update_history_descriptors;

IF descriptors = '{"DbSvDsoStore", "DbSvSvStore"}' THEN
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@rautenrieth-da rautenrieth-da left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Nice cleanup of the useless case dbStorage: DbStorage 🎉

select array_agg(store_name order by store_name) into descriptors
from update_history_descriptors;

IF descriptors = '{"DbSvDsoStore", "DbSvSvStore"}' THEN
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@OriolMunoz-da OriolMunoz-da changed the title [wait until 0.4.21] Disable UpdateHistory for SV and Splitwell apps [wait until 0.5.1] Disable UpdateHistory for SV and Splitwell apps Oct 20, 2025
* Make scanConfig mandatory in SV app

[ci] let's see what breaks

Signed-off-by: Oriol Muñoz <[email protected]>

* [ci] docs

Signed-off-by: Oriol Muñoz <[email protected]>

* [ci] run pls gh

Signed-off-by: Oriol Muñoz <[email protected]>

* update helm json schema

Signed-off-by: Oriol Muñoz <[email protected]>

* [ci] release notes fix

Signed-off-by: Oriol Muñoz <[email protected]>

---------

Signed-off-by: Oriol Muñoz <[email protected]>
Copy link
Contributor

@ray-roestenburg-da ray-roestenburg-da left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Remove UpdateHistory from DbDsoStore

3 participants