# Exercise 1 — Named Volume vs. Bind Mount (easy)
#
# This exercise is a Compose file so both mount types can be shown
# side by side, but the concepts apply identically to a plain `docker run
# -v`.
#
# STEP 1: `app` service, build: ., with a BIND MOUNT of the local ./src
#         directory to /app/src inside the container (so live source edits
#         on the host are visible immediately inside, per theory section 2
#         — this is the local-dev use case for bind mounts).
# STEP 2: `db` service, image postgres:16-alpine, with a NAMED VOLUME
#         `pgdata` mounted at /var/lib/postgresql/data (so data survives
#         container removal, per theory section 3 — this is the
#         persistence use case for named volumes).
# STEP 3: declare `pgdata` as a top-level named volume.
#
# No YAML interpreter self-check — verify against the CHECKLIST below.

services:
  app:
    build: .
    volumes:
      # TODO 1: bind mount ./src (host) -> /app/src (container)
      - TODO

  db:
    image: postgres:16-alpine
    volumes:
      # TODO 2: named volume pgdata -> Postgres data dir
      - TODO

# TODO 3: declare pgdata
volumes:
  TODO:

# ---------------------------------------------------------------------------
# CHECKLIST:
# [ ] `app`'s volume entry starts with `./src` (a relative HOST path),
#     proving it's a bind mount, not a named volume.
# [ ] `db`'s volume entry starts with `pgdata` (a bare NAME, no `./` or
#     `/` prefix), proving it's a named volume, not a bind mount.
# [ ] `pgdata` is declared under the top-level `volumes:` key.
# [ ] Explain in a one-line comment: if you edited a file under ./src on
#     the host while `app`'s container was already running, would the
#     container see that edit without a rebuild or restart? Why (bind
#     mounts are a live kernel-level mount, not a copy)?
# [ ] Explain in a second one-line comment: if `pgdata` were instead
#     written as `./pgdata:/var/lib/postgresql/data` (a bind mount, not a
#     named volume), what practical difference would that make for
#     portability across two different developers' machines?
# ---------------------------------------------------------------------------