Skip to content

Commit c708fd0

Browse files
Update content/blog/2023-04-10-is-latest-patch.Rmd
Co-authored-by: Katie Mazaitis <[email protected]>
1 parent 978be96 commit c708fd0

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

content/blog/2023-04-10-is-latest-patch.Rmd

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ In August 2022, the Delphi team discovered a fault in the data that we were send
2323
Due to the huge volume of COVIDcast data, we are limited in the real-time calculations that we can perform on it. This is because we must maintain a highly available API that can deliver data to end users very quickly. With this in mind, in the previous version of our database, we used a statically set flag that delineated whether a row in the database was the latest version of the data.^[Much of the data that is used to create the COVIDCast API is not complete the first day that it is reported. For instance, COVID cases for a specific day will change for many days to weeks afterwards as the reporting source revises its data. Because of this, we store many different versions of the same reference day for each signal. Usually, our users are most interested in the most recent version of the data. In our previous version of Epidata, version 3, we kept a statically set flag in our table to delineate the latest version of a certain row of data. This flag was set when we ingested a new version of said data. This workflow was very prone to data faults when patching the database outside of the acquisition pipeline (that typically sets the flag). For more information, [check out our blog post on Epidata version 4](https://delphi.cmu.edu/blog/2022/12/14/introducing-epidata-v4/).] We believe that this problem arose when we applied a patch^[A patch, in this context, is a set of data that matches to a database that contains incorrect information. The patch contains the keys to find these rows and update them with the correct information.] to our database and this flag was not properly recalculated.
2424

2525
## How did we identify this?
26-
Data faults like this are difficult to identify. In this case, this fault was found by accident while a member of the Delphi team was working on a new system to calculate metadata. During this, they found that [some of the JHU-CSSE data was not matching up and looked deeper into it](https://github.com/cmu-delphi/covidcast-indicators/issues/1685). The team’s analysis identified 11,987,335 rows that were labeled as the latest issue in which had more recent issues in the database; this constituted about 20% of our JHU-CSSE data at the time.
26+
Data faults like this are difficult to identify. In this case, this fault was found by accident while a member of the Delphi team was working on a new system to calculate metadata. During this, they found that [some of the JHU-CSSE data was not matching up and looked deeper into it](https://github.com/cmu-delphi/covidcast-indicators/issues/1685). The team’s analysis identified 11,987,335 rows that were labeled as the latest issue but which had more recent issues in the database; this constituted about 20% of our JHU-CSSE data at the time.
2727

2828
## How did we fix it?
2929

0 commit comments

Comments
 (0)