Exercise 1: Adding an update() Method — Possible Solution
====================================================================

THE NEW METHOD
------------------------------
    def update(self, conn):
        columns = [c for name, c in self._fields.items() if name != 'id']
        assignments = ', '.join(f"{c} = ?" for c in columns)
        values = [getattr(self, name) for name in self._fields if name != 'id']
        sql = f"UPDATE {self._table} SET {assignments} WHERE id = ?"
        conn.execute(sql, values + [self.id])
        conn.commit()

This follows the chapter's own save() method closely, but builds a real
SQL UPDATE ... SET ... WHERE id = ? statement instead of an INSERT OR
REPLACE -- every column except id gets reassigned, and id itself is
only ever used in the WHERE clause to target the one row being
changed. Every value, including id, still goes through a real ?
placeholder, matching the chapter's own parameterized-query discipline
throughout.

TESTING IT
------------------------------
    a = Author.get(conn, 1)
    print("Before update:", a.name)      # Ann

    a.name = "Annette"
    a.update(conn)

    print("After update, re-fetched:", Author.get(conn, 1).name)   # Annette
    print("Bo, untouched:", Author.get(conn, 2).name)               # Bo

RESULTS, VERIFIED DIRECTLY AGAINST A REAL SQLITE DATABASE
------------------------------------------------------------
    Before update: Ann
    After update, re-fetched: Annette
    Bo, untouched: Bo

Author id=1's own name genuinely changes in the database and survives
a fresh Author.get(conn, 1) call afterward -- not just the in-memory
Python object -- confirming the UPDATE statement actually committed.
Author id=2 (Bo) is completely unaffected, confirming the WHERE id = ?
clause correctly targets only the one row being updated.

WHY THIS WORKS AS AN ANSWER
----------------------------
It adds a real, distinct SQL operation (UPDATE, not INSERT OR REPLACE)
following the chapter's own established column/placeholder pattern,
and verifies the change two ways that matter: the target row's own new
value survives a genuine re-fetch, and a different row is confirmed
untouched by the same operation.