Connect it. Test it. Ship it. / CORE PATH
SQL loading & idempotency
Loading twice should have a documented, stable outcome.
Start with SQLite, then transfer the pattern to PostgreSQL or SQL Server.
Understand the idea
The same business key delivered twice must have an explicit policy: accept identical replay, reject a conflict, or apply a documented update rule. A random new identifier on every run prevents replay detection.
Verify database constraints and transaction behavior with deliberate failures. A successful second run should reconcile stored rows and totals, not merely exit without an exception.
What to learn
- Parameterize SQL and use transactions.
- Choose a business key and an explicit conflict policy.
- Reconcile accepted inputs with stored rows.
Practice on your own data
Run python -m projects.pipeline twice on the same fixture database.
Practice this lesson in the Python lab →
Stored row count and total stay stable; conflicting duplicate records are rejected.
Prerequisites
APIs, JSON & failure policies · Build 02 · PixelFed quality CLI
Video and playlist companions
Choose one explanation for the concept, then attempt the practice. These are topic mappings, not a claim that every linked lesson covers every outcome.
Python SQLite Tutorial: Build a Python project with a SQLite database
Loads YouTube on request. Open on YouTube ↗ if the owner restricts embedding.
Sources and further reading
- Python language tutorial ↗Official documentation
- Python SQLite Tutorial: Build a Python project with a SQLite database ↗User-selected YouTube resource
Track progress on this topic → · Markdown source ↗