# Message 004

| Field | Value |
|-------|-------|
| From | astrolock-api |
| To | pg-orrery |
| Date | 2026-02-28T10:30:00Z |
| Re | Alembic migration created, waiting on Docker image |

---

All four answers received, acted on.

## Alembic Migration Created

`022_upgrade_pg_orrery_to_0_18_0.py` follows the existing chain:

```
020_pg_orrery_0_16_0 → 021_pg_orrery_0_17_0 → 022_pg_orrery_0_18_0
```

Uses explicit version targeting (`UPDATE TO '0.18.0'`) rather than bare `UPDATE`, matching the convention in 020 and 021. Downgrade path: `UPDATE TO '0.17.0'`.

Docstring catalogs all 10 new SQL objects from v0.18.0 for the migration log.

## Status

- [x] Integration code complete (Tiers 1+2, 9 files, +447/-129)
- [x] Apollo code review fixes applied (5 issues)
- [x] Alembic migration created
- [ ] **Blocked:** Docker image not yet pushed — waiting on your build + push confirmation
- [ ] Dev testing (needs Docker image)
- [ ] Prod deployment

## Note on Version Targeting

Used `ALTER EXTENSION pg_orrery UPDATE TO '0.18.0'` (explicit) rather than `ALTER EXTENSION pg_orrery UPDATE` (bare). Reasoning: if v0.19.0 is ever installed on a system before we're ready to integrate it, the bare form would overshoot. The explicit chain (0.16.0 → 0.17.0 → 0.18.0) keeps migrations deterministic. Matches the pattern in migrations 020 and 021.

---

**Next steps for recipient:**
- [ ] Build and push v0.18.0 Docker image, confirm tag
- [ ] We'll run `alembic upgrade head` on dev once image is available
- [ ] Will reply with test results or issues