A Prisma Schema Change Has Three Lifecycles

Prisma Schema 的变更包含三个生命周期

One valid PostgreSQL row refused to appear on my Next.js page. The relationship was correct, the SQL join returned the row, and the repository compiled. At runtime, however, Prisma returned an undefined jobOpportunity relation. The stale layer was not the database—I had changed the Prisma schema while the development server was running.

有一条有效的 PostgreSQL 数据行无法在我的 Next.js 页面上显示。关系定义是正确的，SQL 连接查询也能返回该行，代码库也能正常编译。然而在运行时，Prisma 却返回了一个未定义的 jobOpportunity 关系。过期的层级并非数据库——而是在开发服务器运行期间，我修改了 Prisma Schema。

That change involved three independent lifecycles: prisma migrate updates the database; prisma generate updates the TypeScript client; restarting Next.js replaces the stale generated client held by the running process. The first two steps were complete. The third was not.

这一变更涉及三个独立的生命周期：prisma migrate 更新数据库；prisma generate 更新 TypeScript 客户端；重启 Next.js 则会替换掉运行进程中缓存的旧版客户端。前两个步骤已经完成，但第三步没有。

Coming from PHP and CodeIgniter, this is an important mental-model shift. A request-scoped PHP application normally loads changed code on the next request. A long-running Node.js process can keep generated code and development caches alive. Prisma provides valuable type safety, but it does not remove complexity—it relocates it.

对于从 PHP 和 CodeIgniter 转过来的人来说，这是一个重要的思维模式转变。基于请求作用域的 PHP 应用通常会在下一次请求时加载变更后的代码。而长驻的 Node.js 进程则会保留生成的代码和开发缓存。Prisma 提供了宝贵的类型安全，但它并没有消除复杂性，而是将其转移了。

My new debugging rule is simple: Application edit → trust hot reload. Prisma model change → migrate, generate, restart. Suspicious stale behavior → clear the framework cache and restart. Before rewriting a correct query, identify which layer is stale.

我新的调试规则很简单：应用代码编辑 → 信任热重载；Prisma 模型变更 → 执行 migrate、generate 并重启；出现可疑的过期行为 → 清除框架缓存并重启。在重写正确的查询语句之前，先确定是哪一层过期了。