Prisma 数据模型演进实战：修改 Data Model 并通过 `prisma deploy` 更新 GraphQL API

后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载导读本文基于 Prisma 官方教程中修改数据模型Changing the Data Model一章完整讲解在 Prisma 服务中迭代数据模型的完整闭环为已有User类型新增字段、理解 Prisma 自动维护的createdAt/updatedAt/id特殊字段、通过prisma deploy把本地变更同步到远端并刷新 GraphQL API以及新增Post类型并建立与User的一对多关系含嵌套 mutation 的connect用法与嵌套查询。读完本文你将掌握改模型 → 重新部署 → 验证新 API这一 Prisma 日常开发的核心工作流并了解底层 CLI 与数据模型解析器的实现机制。适用前提本文面向已按 01-Backend 快速入门 完成hello-world服务创建、部署并体验过 GraphQL Playground 的读者。文中命令与行为均以本仓库Prisma 1.xCLI 代码位于 cli/packages/prisma-cli-core实际实现为准。教程脉络从会部署到会演进在前面的教程中你已经完成了三件事部署了一个 Prisma 服务、探索了它的 API、通过 queries 和 mutations 与 API 交互。本教程的目标是把这条链路再向前推进一步——通过修改数据模型来演进 API。将要完成的具体变更如下给User类型新增一个age字段记录User节点初次创建与最后更新的精确时间新增带title字段的Post类型在User与Post之间建立一对多关系表达一个User可以创建多个Post节点。这四步分别覆盖了数据模型变更的三种典型形态标量字段、Prisma 托管字段、类型间关系。它们全部通过同一份数据模型文件如datamodel.graphql/datamodel.prisma声明再经一次prisma deploy生效。第一步为User类型添加字段打开数据模型文件在User类型中加入age、createdAt、updatedAt三个字段type User { id: ID! unique createdAt: DateTime! updatedAt: DateTime! name: String! age: Int }age可选标量字段age的类型是Int且没有!后缀说明它是可选字段。这意味着可以存储age为null的User节点——事实上之前创建的名为Sarah的User在本次变更后其age就会是null。在数据模型中String、Int、Float、Boolean、DateTime、ID、UUID、Json等标量类型由数据模型层统一定义参见 scalar.ts 中的TypeIdentifier类型清单。createdAt与updatedAtPrisma 托管的特殊字段createdAt和updatedAt是由 Prisma 管理的特殊字段。即使数据模型中没有显式声明它们Prisma 在底层也会为每个节点持续维护这两个字段的值只有当你把它们写进数据模型的类型定义时它们才会暴露到 GraphQL API 中id字段同理。从源码层面可以印证这一点数据模型解析器在解析字段时会专门识别这三类保留字段——relationalParser.ts 中的isIdField、isCreatedAtField、isUpdatedAtField分别检查字段是否命中id/createdAt/updatedAt保留名legacyFields.ts 定义了这三个保留名常量同时数据模型指令表中也有对应的id、createdAt、updatedAt指令键见 directives.ts。也就是说只要字段名恰好是这三个保留名Prisma 就会把它当作托管字段处理并自动维护其值。一个重要的使用限制当前版本中这些字段的值是只读的只能通过 mutation 之外的系统行为写入不能通过常规 mutation 显式赋值。当时 Prisma 官方用一个 GitHub issue 跟踪未来允许通过 mutation 设置这些字段值的功能与时间线本文写作时仍以只读为准。本地变更 vs 远端生效到目前为止所有修改都只是本地文件变更。如果此刻打开 GraphQL Playground还访问不到这些新字段——因为远端 API 仍基于旧的数据模型。要让变更生效必须执行部署。第二步prisma deploy——让变更生效、更新 API在hello-world目录下执行prisma deploy部署完成后可以新开一个 GraphQL Playground或者在已打开的 Playground 中重新加载 schema点击 GraphQL API 地址旁边带箭头的Refresh按钮。刷新后User类型上的新字段即可访问。部署背后的实现机制prisma deploy对应 CLI 源码中的 Deploy 命令其完整流程可以概括为加载配置读取prisma.yml其中datamodel属性是必填的——若缺失会直接报错The property datamodel is missing in your prisma.ymldeploy.ts。数据模型文件名datamodel.graphql或datamodel.prisma正是由该属性指定的这也是为什么教程中要求打开datamodel.graphql编辑。确定服务与阶段若prisma.yml未提供 service/stage或显式使用--new会进入交互式EndpointDialog选择 cluster 并回写 endpoint 到prisma.ymldeploy.ts。检查/创建项目通过projectExists判断远端是否已有该项目没有则调用addProject创建 stagedeploy.ts。提交迁移把definition.typesString即整个数据模型 SDL 文本发送给服务端执行部署随后轮询getMigration直到迁移步骤全部 applied 或进入SUCCESS/ROLLBACK_SUCCESS等终态deploy.ts。收尾动作执行post-deployhooks自 Prisma 1.31 起部署成功后会自动隐式执行prisma generate生成客户端若post-deploy里还手动写了 generate hook 会给出重复执行警告新项目首次部署时还会按prisma.yml的seed配置执行数据填充deploy.ts。常用部署参数除基础用法外prisma deploy还支持一批实用 flag见 deploy.ts 中的 flags 定义Flag简写作用--force-f接受 schema 变更可能引起的数据丢失跳过确认--dry-run-d仅预演部署不真正应用变更--new-n强制进入交互模式重新选择 cluster--no-seed—首次部署时禁用 seed 填充--no-migrate—禁用迁移要求 Prisma 1.26--json-j以 JSON 格式输出结果--env-file-e指定注入环境变量的.env文件路径--project-p指定 Prisma 定义文件路径--no-generate—禁用部署后的隐式客户端生成--skip-hooks—跳过post-deployhooks验证新字段带age的创建 mutation字段生效后可以发送如下 mutation创建带age的User节点mutation { createUser(data: { name: John age: 42 }) { id createdAt updatedAt } }注意查询选择集中特意取了createdAt和updatedAt——它们的值由 Prisma 在节点创建时自动写入无需也不允许在data中提供。第三步新增Post类型并建立一对多关系教程的最后一步是在数据模型中加入第二个类型Post并让它与User产生关联。关系建模的自然语法在 Prisma 数据模型中创建关系非常自然只需在某个类型中添加一个指向相关类型的字段就代表了关系的一端。关系可以只声明一端也可以双向声明。先定义新的Post类型及其关系端。在datamodel.graphql中追加type Post { id: ID! unique title: String! author: User! }随后再次在hello-world目录运行prisma deploy使变更生效。这里author: User!是一个必选的User类型字段表示每个Post节点都必须有一个User作为作者。解析器在解析完整 SDL 后会调用resolveRelations把类型间的关系端相互关联起来形成完整的关系图见 parser.ts。用connect完成嵌套 mutation由于author是必选关系字段创建Post时不能只给title还必须通过嵌套 mutation 的connect参数把它连到一个已存在的User节点上mutation { createPost(data: { title: GraphQL is awesome author: { connect: { id: __USER_ID__ } } }) { id } }执行前请把__USER_ID__占位符替换为实际存在的User节点id可以用{ users { id } }查询获取。connect表达的是与已有节点建立关联的语义与之相对的create则用于在嵌套中直接创建关联节点。补齐关系的另一端posts: [Post!]!目前只有Post.author这一端User端还看不到自己的文章。为了让关系成为完整的一对多关系给User类型加上posts字段type User { id: ID! unique createdAt: DateTime! updatedAt: DateTime! name: String! age: Int posts: [Post!]! }posts: [Post!]!表示该User创建的所有Post节点列表列表本身非空!列表内每个元素也非空Post!这是 Prisma 一对多关系在多端的典型声明方式。由于author端是必选从建模角度每个Post必然归属于某个User因此该列表永远不会为空列表的可选性问题——列表字段本身始终存在。嵌套查询一次取回两层数据关系建好后就可以发送嵌套查询同时取回所有User及其各自的Post{ users { name posts { title } } }这个查询演示了关系的查询端能力Prisma 会按关系自动组装结果posts下返回的是该User名下所有Post节点的title。客户端库生成的类型中也包含完整的createdAt/updatedAt过滤与排序输入如createdAt_lt、createdAt_gt等见 prisma-client-lib 的 TypeScript 客户端快照说明这些托管字段一经声明即可参与条件查询。下一步本教程覆盖了 Prisma 数据模型迭代的最小闭环改模型 → 部署 → 验证。在此基础上官方还提供了以下延伸方向快速入门教程Backend 与 Fullstack说明如何把 Prisma 与具体语言/框架如 React、Node.js、TypeScript结合使用见 docs/1.3/01-Quickstart。实战示例仓库维护了一批覆盖具体场景的示例如认证与权限、文件处理、包装 REST API、GraphQL subscriptions 等见 examples/README.md。部署文档了解本地 Docker、Prisma Cloud 等不同部署选项见 docs/1.3/03-Tutorials/04-Cluster-Deployment。此外如果想从零创建一个最小可部署的服务可以参考 CLI 的初始化模板 boilerplate/datamodel.prisma即prisma init生成的最小数据模型以及部署命令的测试用例 deploy/index.test.ts进一步验证prisma deploy在各类配置下的行为。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐Prisma 数据模型变更实战通过修改 datamodel 并执行 prisma deploy 更新 GraphQL APIPrisma 数据模型变更实战通过修改 datamodel 并执行 prisma deploy 更新 GraphQL API 这篇教程承接 Prisma 服务后端数据库GraphQL修改 Prisma 数据模型并更新 GraphQL API字段增删、关系建模与部署实战修改 Prisma 数据模型并更新 GraphQL API字段增删、关系建模与部署实战 本篇指南承接 Prisma 1.x 入门系列围绕 hello wor后端数据库GraphQLPrisma 与 graphql-yoga 实战常见 Resolver 模式与数据模型演进指南Prisma 与 graphql yoga 实战常见 Resolver 模式与数据模型演进指南 导读 本文基于 Prisma 1.x 官方文档中的 Resol后端数据库GraphQL创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考