Exercise 2: In-Memory Databases and the Testing Use Case — Possible Solution
====================================================================

WHAT AN IN-MEMORY SQLITE DATABASE IS
------------------------------
Per this chapter, "sqlite3 :memory: (or the special string ':memory:'
passed in application code) creates a database that exists only in
RAM, never touching disk at all, and disappears completely the moment
the connection closes." Rather than opening or creating a file on
disk, this special connection string tells SQLite to create the
entire database — schema, tables, and all data — purely in the
process's own memory, with nothing ever written to persistent storage.

THE CONCRETE TESTING USE CASE
------------------------------
Per this chapter, "it's a genuinely common real-world pattern in
automated testing — spinning up a fresh, empty in-memory database for
each test run guarantees complete isolation between runs with zero
cleanup required." Automated test suites often need a real database
to test actual queries and data-access logic against. Using
:memory: for this means each individual test (or each test run) gets
its own brand-new, completely empty database, with no risk of leftover
data from a previous test run leaking into the current one — a
genuine, common problem when tests share a real, persistent database
file.

WHY CLEANUP BECOMES A NON-ISSUE
------------------------------
Per this chapter, the database "disappears completely the moment the
connection closes," and "the 'database' simply ceases to exist the
moment the test process ends." With a normal, file-based database,
running automated tests requires actively cleaning up afterward —
deleting test data, resetting tables, or removing a temporary file —
so the next test run isn't affected by leftover state. With an
in-memory database, there's nothing to clean up at all: closing the
connection (which naturally happens when a test finishes) makes the
entire database vanish on its own, with no explicit deletion step, no
leftover file on disk, and no possibility of one test's data
accidentally surviving into the next.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines the mechanism precisely (RAM-only, gone on connection
close) using the chapter's own wording, and explains specifically WHY
this eliminates the cleanup step real file-based test databases would
otherwise require, rather than just asserting that it's "convenient."