Personal Catalogue: Django & PostgreSQL — Chapter 2, Exercise 1
====================================================

TASK
Write all three model classes from this chapter in catalogue/models.py,
run makemigrations and migrate, and confirm the real PostgreSQL tables
were created using psql's own \dt command.

SOLUTION

catalogue/models.py should contain, in this order (ItemType and Tag
first, since Item references both):

    from django.db import models

    class ItemType(models.Model):
        name = models.CharField(max_length=20, unique=True)

        def __str__(self):
            return self.name

    class Tag(models.Model):
        name = models.CharField(max_length=50, unique=True)

        def __str__(self):
            return self.name

    class Item(models.Model):
        item_type = models.ForeignKey(ItemType, on_delete=models.PROTECT)
        title = models.CharField(max_length=255)
        creator = models.CharField(max_length=255, blank=True)
        format_detail = models.CharField(max_length=100, blank=True)
        release_year = models.PositiveSmallIntegerField(null=True, blank=True)
        notes = models.TextField(blank=True)
        created_at = models.DateTimeField(auto_now_add=True)
        tags = models.ManyToManyField(Tag, blank=True, related_name='items')

        def __str__(self):
            return self.title

Then run:

    python manage.py makemigrations catalogue
    python manage.py migrate

CONFIRMING THE REAL TABLES

Connect to the database with psql and list its tables:

    psql -U postgres -d catalogue
    \dt

The output should include catalogue_itemtype, catalogue_tag,
catalogue_item, and a fourth table Django generated automatically for
the many-to-many relationship, named something like
catalogue_item_tags. Django prefixes table names with the app's own
label (catalogue) by default, which is why the table names don't
exactly match the model class names.

WHY THIS WORKS AS AN ANSWER
----------------------------
It defines the models in the correct dependency order (referenced
models before the model that references them), runs the real two-step
migration process, and verifies the outcome directly against the live
database rather than just trusting that the commands ran without error.