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

TASK
Set up the catalogue PostgreSQL database and a working Django project
connected to it yourself, then write a one-sentence explanation of what
python manage.py migrate actually confirmed by running successfully.

SOLUTION

This exercise is a hands-on setup task — the real steps to follow are
exactly the ones in the chapter itself: create the database with
`CREATE DATABASE catalogue WITH ENCODING 'UTF8';`, run
`django-admin startproject catalogue_site .` and
`python manage.py startapp catalogue`, point `DATABASES` in
`settings.py` at the real database, add `'catalogue'` to
`INSTALLED_APPS`, then run `python manage.py migrate`.

WHAT A SUCCESSFUL MIGRATE ACTUALLY CONFIRMS

`python manage.py migrate` doesn't just create empty database tables in
the abstract — it applies Django's own built-in migrations (covering
things like the admin interface, authentication, and sessions) as real
SQL statements sent over the actual connection defined in `DATABASES`.
If that connection information were wrong - a bad host, an incorrect
password, a database that doesn't actually exist yet - the command would
fail with a real, visible connection error rather than silently doing
nothing.

A successful run, in other words, is a real end-to-end proof that the
project's Python code, Django's own settings, and the live PostgreSQL
server are all correctly connected and able to exchange real data -
not just that the individual pieces were each installed correctly in
isolation.

ONE-SENTENCE ANSWER: A successful `python manage.py migrate` confirms
that Django's own settings.py configuration, the installed psycopg2
adapter, and the live PostgreSQL server are all genuinely connected and
able to execute real SQL against the catalogue database, not merely
that each piece was installed without error on its own.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains specifically what the migrate command does (applies real SQL
against a live connection) rather than treating it as a generic "it
worked" checkbox, and distinguishes a genuine end-to-end connection test
from simply confirming each dependency installed successfully in
isolation.