Exercise 3: The Silent-Typo Gotcha vs. MySQL/Postgres's Loud Failure — Possible Solution ==================================================================== WHAT HAPPENS IN SQLITE WHEN A PATH HAS A TYPO ------------------------------ Per this chapter's own warn-box, "since there's no CREATE DATABASE step and no authentication, running sqlite3 against a path that has a typo... doesn't produce a 'database not found' error the way connecting to a nonexistent MySQL or Postgres database would. SQLite will happily create a brand-new, empty database file at whatever path was given, silently, if the file doesn't already exist." Because sqlite3 (and any SQLite connection call) treats "the file doesn't exist yet" as a completely normal, expected situation — per this chapter's own Ch.2 opening material, that's exactly how a brand-new database gets created in the first place — a typo'd path is indistinguishable, from SQLite's own point of view, from a legitimate request to create a new database at that exact (mistaken) path. WHAT HAPPENS IN MYSQL/POSTGRES WHEN A CONNECTION HAS A TYPO ------------------------------ In MySQL or Postgres, connecting requires specifying an actual database that must already exist on a running server the client is authenticating against — a typo in the database name, host, or credentials results in the server (or the client) immediately rejecting the connection attempt with a clear, loud error (something like "unknown database" or "authentication failed"). The mistake is caught immediately, before any work can be done against the wrong target. THE SPECIFIC, DIFFERENT KIND OF MISTAKE THIS CAUSES IN SQLITE ------------------------------ Rather than an immediate, obvious failure, a typo'd SQLite path produces a WORKING SESSION against a brand-new, completely empty database that happens to sit at the wrong path — indistinguishable, at first glance, from a legitimate empty database. Someone could run queries, insert data, and work productively for a while against this accidental database before eventually noticing something is wrong (perhaps when expected pre-existing data doesn't appear) — a silent, delayed-discovery mistake, rather than the loud, immediate failure a MySQL/Postgres connection typo produces. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why SQLite can't distinguish a typo from a legitimate new-database request (per the chapter's own reasoning about file existence), contrasts this against MySQL/Postgres's own immediate, loud connection-failure behavior, and names the specific consequence — a silently wrong, working database rather than an obvious error.