Exercise 3: Why Undo Can't Just Restore the Value — Possible Solution
====================================================================

WHY UNDO CAN'T SIMPLY SET IT BACK
------------------------------
Once mark_used runs and item.save() commits expiry_date = None to the database, the row's original expiry date value is genuinely no longer stored anywhere in that row - it has been overwritten, not hidden or archived. There is no remaining copy of the original value left in the Item row itself for an undo action to read back and restore; the information simply isn't there anymore once the save has happened.

WHAT A GENUINE UNDO WOULD NEED TO DO INSTEAD
------------------------------
A real undo feature would need to have captured and temporarily stored the original expiry date somewhere else before clearing it - for example, briefly in the user's session, specifically to support a short "undo" window immediately after the action - or, failing that, simply ask the user to re-enter the expiry date manually, since the application has no way to recover a value it already told the database to overwrite.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the original value is genuinely gone once mark_used commits the change, not merely hidden, and correctly identifies that a real undo implementation would need to preserve the value elsewhere before clearing it, or ask the user to supply it again, rather than assuming the database itself retains a recoverable copy.