Skip to content
All projects
Core engineering libraryData Manager

dump_upload_pipeline.py — Mobile-Dump Ingestion

BCHPR · NPOC and Wave 11 · 2024 – present

Built to end a specific failure: the notebook it replaced created duplicate patients three ways. Repeated QR codes were suffixed −1, −2 and uploaded as separate people; a field phone syncing straight to REDCap produced a second unlinked record for someone already dumped; and merging forms before upload multiplied rows. Duplicate enrolment inflates the denominator, which is an endpoint-validity problem, not a tidiness one.

Highlights

  • Participant identity is a canonical QR code per row; change detection is a SHA-256 hash over the form's key columns, normalised so that “5.0” and “5” hash identically.
  • Idempotency enforced structurally — SQLite primary keys plus INSERT OR IGNORE, so a crashed and restarted run cannot double-write.
  • Nine pipeline stages across 10 tables and two databases, with a review queue holding six kinds of conflict for human adjudication rather than guessing.
  • File-change detection is size and mtime, not content hash — a SharePoint touch costs one cheap CSV re-read, where hashing every file every run costs far more.
  • A salvage path for dumps arriving as JSON-wrapped CSV, added after six files in one site produced between 46,000 and 123,000 phantom columns each.
  • Journal mode chosen by filesystem: WAL normally, DELETE on network and NTFS mounts where shared memory is unavailable.
  • Uploads run thread-parallel over HTTP while every SQLite write stays on the main thread, keeping a single writer.