Personal Catalogue: React, Express & MongoDB — Chapter 3, Exercise 3
=====================================================================

TASK
Explain why the PUT route has to look up which discriminator model
applies before calling findByIdAndUpdate, while the DELETE route works
correctly using only the base Item model with no such lookup at all.

SOLUTION

The PUT route:

  const existing = await Item.findById(req.params.id);
  const Model = MODEL_MAP[existing.itemType];
  const updated = await Model.findByIdAndUpdate(req.params.id, req.body, {
    new: true,
    runValidators: true,
  }).lean();

The DELETE route:

  const deleted = await Item.findByIdAndDelete(req.params.id);

An update is a schema-aware operation. It has to decide, for every field
in the request body, whether that field is allowed to be set and
whether the value passed is valid for that field's own type. That
decision genuinely depends on which schema applies: updating a Book's
own author field is only meaningful if the update runs through a model
that actually knows author exists and what type it should be. Running
the update through the base Item model instead would apply Item's own
schema rules, which don't recognize author at all -- the exact same
field-visibility problem Exercise 2 reproduced for reads, but now on a
write. That's why PUT has to fetch the existing document first, read
its real itemType, and route the actual update call through the
matching model in MODEL_MAP.

A delete is not a schema-aware operation at all. "Remove the document
whose _id matches this value" doesn't reference a single field defined
by any schema -- it only needs the _id, which every document in the
items collection has regardless of which discriminator created it.
MongoDB doesn't need to know or care whether the document being deleted
has an author field, a director field, or neither; it just removes
whatever's stored at that _id. Since no field-level validation or
casting is happening, there's no schema whose rules could differ from
another's, so there's nothing to look up.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the real distinguishing factor -- whether the operation
has to interpret specific fields against a specific schema, not just
"whether it's a write" -- and shows why that factor applies to create
and update but not to delete, using the same field-visibility mechanism
already established in Chapter 2 and Exercise 2 rather than introducing
a new, unrelated explanation.