Personal Catalogue: PHP & MySQL — Chapter 8, Exercise 3
====================================================

TASK
Explain, in your own words, what would go wrong for the user
experience if bulk_add.php's own loop ran each INSERT without a
surrounding transaction, and a genuine database error occurred after
15 of 40 pasted titles had already been inserted.

SOLUTION

Without a transaction, each INSERT inside the loop is its own
completely independent, immediately-committed database change — the
moment execute() succeeds for a given title, that row is permanently
saved to disk, with no connection at all to whether any of the other
39 titles in the same paste later succeed or fail.

If a genuine database error occurred on title 16 (say, MySQL's own
connection dropped, or the server ran out of disk space mid-batch),
the loop would stop there with an uncaught exception. At that point,
titles 1 through 15 are already permanently committed to the items
table — real rows, fully saved — while titles 16 through 40 were
never inserted at all. The user is left with a genuinely confusing,
half-imported result: the catalogue now contains some, but not all,
of the pasted list, with no clear record of which 15 of the original
40 actually made it in, and no easy way to tell without manually
comparing the pasted text against the database by hand.

With the transaction wrapping the whole loop (as the chapter actually
builds it), the same error at title 16 triggers the catch block's own
rollBack() call, which undoes every insert from that batch — including
the 15 that had already succeeded within the same transaction, since
none of them were ever actually committed to disk yet. The user is
left with a clean, honest, all-or-nothing result: either the whole
batch went in, or none of it did, with no confusing partial state to
sort out by hand.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies the real, concrete consequence (a genuinely
confusing half-imported database state with no clean record of what
succeeded) rather than a vague "it's less safe," and explains why the
transaction specifically prevents that outcome by keeping every insert
in the batch uncommitted until the very end.