|
| 1 | +# Chapter 6: Registration Service |
| 2 | + |
| 3 | +This is the final version of the chapter's SQLAlchemy service, including the three exercises. It uses Python 3.13 and uv. Run these commands from this directory: |
| 4 | + |
| 5 | +```bash |
| 6 | +uv sync |
| 7 | +uv run alembic upgrade head |
| 8 | +uv run fastapi dev main.py |
| 9 | +``` |
| 10 | + |
| 11 | +Open http://127.0.0.1:8000/docs to register, list, read, update, and delete users. This is a teaching example with no authentication or authorization; do not expose it publicly. Access controls are covered later in the book. |
| 12 | + |
| 13 | +## Database setup |
| 14 | + |
| 15 | +SQLite is the default and needs no server. The final application does not create tables at startup: run the committed migrations before starting it against an empty database. Do not generate a second initial migration. If following the earlier `create_all` example, use a fresh database for the migration walkthrough rather than applying the initial migration to an existing `users` table. |
| 16 | + |
| 17 | +For PostgreSQL, provision a database and supply a `postgresql+asyncpg` connection URL through `DATABASE_URL` using your deployment's secret management. Never commit real credentials. Run the same migrations and `uv run python check_db.py` before starting the service. The check script also supports SQLite. |
| 18 | + |
| 19 | +The migrations create the seven-column users table, add the optional phone number, and add JSON preferences. Preferences use JSONB on PostgreSQL and JSON on SQLite. Python-side defaults are applied by SQLAlchemy, not by direct database inserts. |
| 20 | + |
| 21 | +## Tests |
| 22 | + |
| 23 | +```bash |
| 24 | +uv run pytest -v |
| 25 | +uv run ruff check . |
| 26 | +``` |
| 27 | + |
| 28 | +Tests use temporary SQLite databases and do not connect to the configured application database. They cover the chapter's eight API cases, stored password hashing, validation, pagination, concurrent-duplicate handling, and migration upgrades/downgrades that preserve existing users. PostgreSQL integration must be checked separately against a running server. |
| 29 | + |
| 30 | +Compared with the printed snippets, the runnable service also returns 409 if a duplicate insert wins a race and rejects explicit null updates to non-nullable columns. Omitted update fields remain unchanged. |
| 31 | + |
| 32 | +## Exercises |
| 33 | + |
| 34 | +- **6.1:** `crud.get_users` and `GET /users` provide pagination ordered by user ID, with validated bounds. |
| 35 | +- **6.2:** `User.phone_number`, `UserBase.phone_number`, and migration `0002` add an optional phone number without deleting users. |
| 36 | +- **6.3:** `exercises/slot_repository.py` implements Chapter 3's `AvailabilitySlotRepository`. It imports the existing domain rather than duplicating it; pytest adds the Chapter 3 service to its Python path. The tests also run the unchanged Chapter 3 use cases against this adapter. |
| 37 | + |
| 38 | +The slot repository is synchronous because Chapter 3's repository interface is synchronous. Its separate metadata is not part of the registration database migrations. Construct it with a SQLAlchemy `sessionmaker` and inject it in place of the in-memory repository. The example does not implement concurrent reservation conflict detection. |
0 commit comments