Challenge 1: Add a ForeignKey Relationship — Possible Solution
====================================================================

# catalog/models.py

from django.db import models

class Publisher(models.Model):
    name = models.CharField(max_length=150)

    def __str__(self):
        return self.name

class Author(models.Model):
    name = models.CharField(max_length=150)

    def __str__(self):
        return self.name

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(Author, on_delete=models.CASCADE, related_name="books")
    publisher = models.ForeignKey(
        Publisher,
        on_delete=models.PROTECT,
        related_name="books",
    )

    def __str__(self):
        return self.title

# Don't forget the migration:
#   python manage.py makemigrations catalog
#   python manage.py migrate

WHY PROTECT INSTEAD OF CASCADE HERE
--------------------------------------
CASCADE means "if the Publisher is deleted, delete every Book that
references it too" — that's a reasonable default for author/book (an
author's books likely don't make sense without that author), but for
publisher/book it's much more likely you'd want to know a publisher has
existing books BEFORE deleting it, rather than silently wiping out an
entire catalog of books the moment someone deletes a publisher record by
mistake. PROTECT raises a ProtectedError instead of deleting the books,
forcing a deliberate decision (reassign the books to a different
publisher, or confirm the deletion is genuinely intended) rather than an
accidental cascade of data loss.

WHY THIS WORKS
--------------
- Both Author and Publisher use ForeignKey on Book, but with different
  on_delete behaviors chosen deliberately based on what SHOULD happen in
  each real-world scenario — on_delete isn't a one-size-fits-all setting,
  and CASCADE (the choice used for the author relationship in the
  chapter) isn't automatically the "correct" default for every
  relationship.
- related_name="books" is reused on both relationships, but since it's
  set independently on the author FK and the publisher FK, each produces
  its own distinct reverse accessor (author.books and publisher.books) —
  they don't conflict with each other because they live on different
  models.
- Running makemigrations/migrate after adding a new field to an existing
  model is the same workflow from Chapter 5 — Django detects the new
  `publisher` column and generates the appropriate ALTER TABLE migration.