Closed Marigold closed 3 weeks ago
Quick links (staging server): Site | Admin | Wizard |
---|
Login: ssh owid@staging-site-fix-metadata-checksum
Edited: 2024-06-12 13:43:56 UTC Execution time: 12.64 seconds
dimensions
- these are not causing problems, but are already captured in dataChecksum
Would they? For instance, if we use indicator upgrader and change the use of an indicator for another, an ID in dimensions
will be changed. This should captured as a 'config change'. I just wonder, would such changes be captured by checksum and config?
Sorry, I don't think I got it, but let me try anyway :).
For instance, if we use indicator upgrader and change the use of an indicator for another, an ID in dimensions will be changed.
If you change an indicator (or did you want to say entity?) then grapher config will change (which is the most important). dimensions
are computed directly from data. The thing is that if you change an entity name, with dimensions it'd show up as both data change and metadata change.
ah, nvm, I got confused. I was thinking of chart.config.dimensions
! All clear sir!
Metadata checksum should be as consistent as possible. There are problematic fields like
updatedAt
that can change even though it has no effect on metadata and should be excluded from checksum calculation.This PR adds a couple more fields that cause problems
dataChecksum
,metadataChecksum
- including these would lead to a feedback loop of ever-changing checksumsdimensions
- these are not causing problems, but are already captured indataChecksum
IDs
- staging server and production can build ETL separately and end up with different ids (but same metadata)TODO after merging:
variables.metadataChecksum
in production DB (we're not going to backfill them all, this will be done in the future when incrementing ETL epoch)