Files

T

Jeffery f44200f543 feat: 完成 B 群組 — 資料層與核心領域模型

- 導入 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 群組冒煙測試無回歸。

2026-08-13 09:43:15 +08:00

2.9 KiB

Raw Blame History

prisma db push

Pushes schema changes directly to database without creating migrations. Ideal for prototyping.

Command

prisma db push [options]

What It Does

Syncs your Prisma schema to the database
Creates database if it doesn't exist
Does NOT create migration files
Does NOT track migration history

Options

Option	Description
`--force-reset`	Force a reset of the database before push
`--accept-data-loss`	Ignore data loss warnings
`--schema`	Custom path to your Prisma schema
`--config`	Custom path to your Prisma config file
`--url`	Override the datasource URL from the Prisma config file

When Prisma detects an AI agent, --force-reset and --accept-data-loss require explicit user consent. Follow agent-safety.md; never infer or fabricate the consent text.

Follow-up Command

Run prisma generate explicitly when you need refreshed client output

Examples

Basic push

prisma db push

Accept data loss

prisma db push --accept-data-loss

Required when changes would delete data (dropping columns, etc.)

Force reset

prisma db push --force-reset

Completely resets database and applies schema.

Full workflow

prisma db push
prisma generate

When to Use

Prototyping - Rapid schema iteration
Local development - Quick schema changes
MongoDB - Primary workflow (migrations not supported)
Testing - Setting up test databases

When NOT to Use

Production - Use migrate deploy
Team collaboration - Use migrations for trackable changes
When you need rollback - Migrations provide history

Comparison with migrate dev

Feature	db push	migrate dev
Creates migration files	No	Yes
Tracks history	No	Yes
Requires shadow database	No	Yes
Speed	Faster	Slower
Rollback capability	No	Yes
Best for	Prototyping	Development

MongoDB Workflow

MongoDB doesn't support migrations. Use db push exclusively:

# Schema changes for MongoDB
prisma db push
prisma generate

Common Patterns

Prototyping workflow

# Make schema changes
# ...

# Push to database
prisma db push

# Generate client
prisma generate

# Test your changes
# Repeat as needed

Reset and start fresh

prisma db push --force-reset
prisma db seed

Handling conflicts

If db push can't apply changes safely:

Error: The following changes cannot be applied:
  - Removing field `email` would cause data loss
  
Use --accept-data-loss to proceed

Decide whether data loss is acceptable, then:

prisma db push --accept-data-loss

Transition to Migrations

When ready for production, switch to migrations:

# Create baseline migration from current schema
prisma migrate dev --name init

Then use migrate dev for future changes.

2.9 KiB Raw Blame History