Embed migrations from the single root directory - #266
Conversation
`embed_migrations!()` embedded a copy of the migrations under
`crates/nvisy-postgres/src/migrations`, kept in sync from the root `migrations/`
by a `make generate-migrations` copy step. That duplication was a silent
split-brain risk: editing a root migration without regenerating left the compiled
binary embedding a stale copy.
Point `embed_migrations!` at the root directory directly
(`embed_migrations!("../../migrations")`, resolved from the crate manifest) so
there is one source of truth. The diesel CLI already ran against `./migrations`
(per `diesel.toml`), so the copy only ever fed the macro.
- `build.rs` reruns on `../../migrations` (not the deleted copy), preserving the
rebuild-on-migration-change behavior the proc-macro limitation needs.
- Drop the copy/mkdir/rm steps and the `MIGRATIONS_IN_DIR`/`MIGRATIONS_OUT_DIR`
vars from `generate-migrations` and `clear-migrations`; they only run and revert
now.
- Remove the redundant embedded copy directory (it was gitignored / untracked).
Verified: `make generate-migrations` regenerates an identical `schema.rs`, and the
copy directory no longer reappears.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018bKk1YEG4tZ69jzYVQvQL8
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (4)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour. 📝 WalkthroughWalkthroughThe migration workflow now uses the repository-root ChangesMigration source consolidation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Migration embedding and generation now use the repository-root migrations directory as the single source of truth, removing the copy workflow without identified current-head merge risk. Sequence Diagram(s)sequenceDiagram
participant Developer
participant Makefile
participant Diesel
participant RootMigrations
participant nvisy-postgres
Developer->>Makefile: Run migration command
Makefile->>RootMigrations: Use canonical migrations
Makefile->>Diesel: Run or revert migrations
Diesel->>Makefile: Generate schema output
nvisy-postgres->>RootMigrations: Embed migrations during build
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Problem
embed_migrations!()embedded a copy of the migrations undercrates/nvisy-postgres/src/migrations, kept in sync from the canonical rootmigrations/by a copy step inmake generate-migrations. That duplication was a silent split-brain risk: editing a root migration without regenerating left the compiled binary embedding a stale copy — no error, just drift between the DB and the binary.Change
Point
embed_migrations!at the root directory directly —embed_migrations!("../../migrations"), resolved from the crate's manifest dir — so there is one source of truth. The diesel CLI already ran against./migrations(perdiesel.toml); the copy only ever fed the macro.build.rsnow reruns on../../migrations(not the deleted copy), preserving the rebuild-on-change behavior the proc-macro's limitation requires.MIGRATIONS_IN_DIR/MIGRATIONS_OUT_DIRvars;generate-migrationsnow just runs migrations + regeneratesschema.rs, andclear-migrationsjust reverts.diesel.tomlcomment.Verification
make generate-migrationsregenerates an identicalschema.rs(no diff), confirming the root migrations produce the same schema. The copy directory does not reappear. Full gate green:cargo check(workspace), clippy (-D warnings),fmt --check.🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Documentation