Jeffery
f44200f543
- 導入 Prisma 7.9.1 + SQLite（better-sqlite3 driver adapter），prisma.config.ts 管理連線設定 - 完整資料模型：User／Work／Character／CharacterAlias／EpisodicMemory／SemanticMemory／ ProceduralRule／EmotionState／Relationship／SentimentLedgerEntry - packages/db：Prisma Client 存取層（ESM，因 Prisma 7 產出的 generated client 僅支援 ESM） - apps/api 隨之改為 ESM 以相容 packages/db - packages/shared：新增角色／記憶／情緒／關係共用型別，api 與 web 皆從此匯入 - prisma/seed.ts：建立測試使用者與元氣型測試角色，含完整關係帳本與記憶種子資料 - apps/api：新增 GET /characters - scripts/smoke/B.mjs：驗證資料表齊全、API 讀出種子角色、關係與記憶可寫入讀出 - 保留 Prisma 官方隨 CLI 附的 agent skill 文件（.agents/skills 等），供後續群組查閱 npm run restart && npm run smoke -- B 皆通過（B-V），A 群組冒煙測試無回歸。
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
# migrations-mapping
|
|
|
|
How the v6 MongoDB "no migrations" story maps onto Prisma Next's first-class migration flow.
|
|
|
|
## Priority
|
|
|
|
HIGH
|
|
|
|
## Why It Matters
|
|
|
|
This is the largest workflow change in the migration — in v6, MongoDB explicitly has no
|
|
Prisma Migrate, while in Prisma Next MongoDB participates in the full migration lifecycle.
|
|
Teams porting a `db push` habit into Next without understanding the plan/verify/sign flow
|
|
will fight the tooling or bypass its safety rails.
|
|
|
|
## v6: `db push` only
|
|
|
|
MongoDB on v6 has no Prisma Migrate and no plans to add it — "MongoDB projects do not rely
|
|
on internal schemas" ([no support for Prisma Migrate](https://www.prisma.io/docs/orm/overview/databases/mongodb#no-support-for-prisma-migrate)).
|
|
The workflow is `prisma db push` to sync indexes and unique constraints, with no migration
|
|
history on disk.
|
|
|
|
## Prisma Next: first-class, contract-driven migrations (Mongo included)
|
|
|
|
Migration authoring in Next is first-class for Postgres **and Mongo** (prisma-next
|
|
`skills/prisma-next-migrations/SKILL.md`) — MongoDB is not a push-only special case:
|
|
|
|
- **Flow:** contract *emit* → diff → *plan* (writes a content-hashed migration package) →
|
|
*migrate* (apply in graph order) → *verify* (live schema vs destination contract) →
|
|
*sign* (advance the marker after a verify pass).
|
|
- **Mongo migration ops** come from dedicated factories: `createCollection`,
|
|
`dropCollection`, `validatedCollection`, `setValidation`, `createIndex`, `dropIndex`,
|
|
`collMod`, and `dataTransform` for data backfills.
|
|
- **Marker storage:** Next records migration state in a document in the
|
|
`_prisma_migrations` collection (per space) — the same collection name family v6 users
|
|
know from SQL, repurposed for Mongo state.
|
|
- **DDL is not transactional on Mongo:** the runner applies operations, verifies the live
|
|
schema against the destination contract, and only advances the marker on a verify pass —
|
|
making interrupted runs resumable rather than atomic (see Prisma Next's
|
|
`prisma-next-migrations` skill).
|
|
- **Push-style alternative still exists:** `db update` diffs the live database against the
|
|
contract and applies directly without writing a migration directory — the closest
|
|
analogue to the v6 `db push` habit, at the cost of no history.
|
|
- Validators: Next emits closed `$jsonSchema` validators by default since 0.12 (prisma-next
|
|
`CHANGELOG.md`) — collections gain schema enforcement v6 never applied.
|
|
|
|
## Bad
|
|
|
|
```text
|
|
Porting the v6 habit: run the Next equivalent of `db push` for every change in production,
|
|
accumulating no migration history, and hand-editing collections when verification fails.
|
|
```
|
|
|
|
## Good
|
|
|
|
```text
|
|
Adopt the Next lifecycle: emit the contract, plan a migration package, apply it with
|
|
migrate, let verify gate the marker, and sign. Reserve `db update` for local prototyping,
|
|
mirroring how `db push` was used on v6.
|
|
```
|
|
|
|
## References
|
|
|
|
- [v6: no Prisma Migrate for MongoDB](https://www.prisma.io/docs/orm/overview/databases/mongodb#no-support-for-prisma-migrate)
|
|
- Prisma Next migrations skill (`skills/prisma-next-migrations`) — authoritative for the Next side; verified @ `a2791c5dd59d579b4b3052942ae7f8fe5e2ee852`
|