部署和管理 Data Connect 架构和连接器

Firebase Data Connect 服务有三个主要组件:

  • 具有自己的 SQL 架构的底层 PostgreSQL 数据库
  • Data Connect 应用架构(在 .gql 文件中声明)
  • 多个连接器(在您的 .gql 文件中声明)。

SQL 架构是数据的可信来源,Data Connect 架构是连接器查看这些数据的方式,连接器声明客户端可以用来访问这些数据的 API。

使用 CLI 部署 Data Connect 服务时,您需要先迁移 SQL 架构,然后更新 Data Connect 架构,最后更新每个连接器。

重要的部署概念

为了充分理解 Deployment,请务必注意 架构和连接器

架构部署

部署 Data Connect 架构会影响 Cloud SQL 数据库的 SQL 架构。Data Connect 可帮助您迁移架构 无论您是要使用新数据库还是需要 无损地调整现有数据库。

Data Connect 项架构迁移有两个不同的架构验证 模式:strictcompatible

  • 严格模式验证要求数据库架构与 然后才能更新应用架构不限 您的 Data Connect 架构中未使用的表或列 都将从数据库中删除

  • 兼容模式验证要求数据库架构兼容 然后才能更新应用架构;任意 删除架构、表或列的其他更改是可选的。

    兼容意味着架构迁移仅影响表和列 在应用架构中引用。数据库中未被应用架构使用的元素会保持不变。因此,部署后,您的数据库可能包含未使用的:

    • 架构
    • Tables

连接器部署

Data Connect 查询和更改操作不是由客户端代码提交并在服务器上执行的。相反,在部署时,这些 Data Connect 操作会存储在服务器上,例如 Cloud Functions。这意味着部署可能会中断现有用户。

遵循部署工作流

您可以在本地项目目录和 Firebase 控制台中处理 Data Connect 项目。

推荐的部署流程包括:

  1. 列出当前部署的架构和连接器firebase dataconnect:services:list
  2. 管理任何架构更新
    1. 使用 firebase dataconnect:sql:diff 检查 Cloud SQL 数据库与本地 Data Connect 架构之间的 SQL 架构差异。
    2. 如果需要,请使用 dataconnect:sql:migrate 执行 SQL 架构迁移。
  3. 通过运行 firebase deploy 执行架构和连接部署, 无论是架构、连接器还是资源组合。

部署和管理 Data Connect 资源

建议您先验证生产环境资源,然后再执行部署。

firebase dataconnect:services:list

在本地项目目录中工作时,您通常需要使用 firebase deploy 命令,将架构和连接器部署到生产环境中, 互动反馈。

无论使用任何 deploy 命令,--only dataconnect 标志都可以让您分隔 您项目中其他产品的 Data Connect 项部署。

正常部署

firebase deploy --only dataconnect

在此正常部署中,Firebase CLI 会尝试部署您的架构 和连接器。

它会验证新架构不会破坏任何现有连接器。 进行破坏性更改时,请遵循最佳实践

它还会在更新 Data Connect 架构。如果没有,它会自动提示您完成 迁移架构所需的步骤。

--force 标志部署

firebase deploy --only dataconnect --force

如果连接器或 SQL 架构验证都没有问题,您可以使用 --force 重新运行命令以忽略它们。

--force 部署仍会检查 SQL 架构是否与 Data Connect 架构匹配,并在发现不兼容时发出警告并提示。

部署所选资源

如需进行更精细的部署,请将 --only 标志与 serviceId 参数。如需仅部署特定服务的架构更改,请执行以下操作:

firebase deploy --only dataconnect:serviceId:schema

您还可以为指定的连接器和服务部署所有资源。

firebase deploy --only dataconnect:serviceId:connectorId

最后,您可以为单个服务部署架构和所有连接器。

firebase deploy --only dataconnect:serviceId

回滚部署

如需手动回滚,请检出代码的先前版本并进行部署。如果原始部署包含破坏性重大更改,您可能无法完全恢复任何已删除的数据。

迁移数据库架构

如果您要快速进行原型设计、尝试架构,并且了解自己的架构 这些更改具有破坏性,因此您可以考虑使用Data Connect工具 核实更改并监督更新的执行方式。

比较 SQL 架构更改

您可以通过以下方式验证更改:

firebase dataconnect:sql:diff

您可以传递逗号分隔的服务列表。

该命令将服务的本地架构与 相应的 Cloud SQL 数据库。如果有差异,它会输出 可以运行以修复差异的 SQL 命令

应用更改

当您对架构 Cloud SQL 实例的更改感到满意并准备好部署更改时,请发出 firebase dataconnect:sql:migrate 命令。系统会提示您批准更改。

firebase dataconnect:sql:migrate [serviceId]

在交互式环境中,系统会显示 SQL 迁移语句和操作提示。

在严格模式或兼容模式下进行迁移

在全新项目中,系统会应用默认的架构验证模式migrate 命令的行为是应用所有数据库架构 更改应用架构所需的更改,然后提示您批准 删除架构、表或列以强制您的数据库的可选操作 与您的应用架构完全匹配

您可以通过修改 dataconnect.yaml 文件来调整此行为。取消注释 schemaValidation 键,并声明 COMPATIBLE,以便仅 都会应用必要的更改

schemaValidation: "COMPATIBLE"

或者将行为设置为 STRICT,以便应用所有架构更改,并强制使数据库架构与应用架构保持一致。

schemaValidation: "STRICT"

如需了解详情,请参阅 Data Connect CLI 参考文档

管理架构和连接器的最佳做法

Firebase 建议在您的Data Connect中遵循一些做法 项目。

尽量减少破坏性更改

  • Firebase 建议您将 Data Connect 架构和连接器文件保存在源代码控制系统中。
  • 尽可能避免破坏性更改。一些常见的故障示例 更改包括:
    • 从架构中移除字段
    • 将架构中的可为 null 字段设为不可为 null(即 Int -> Int!
    • 重命名架构中的字段。
  • 如果您确实需要从架构中移除字段,请考虑将其拆分为多个部署,以尽可能降低影响:
    • 首先,移除连接器中对该字段的所有引用,然后部署更改。
    • 接下来,更新您的应用以使用新生成的 SDK。
    • 最后,移除架构 .gql 文件中的字段,迁移 SQL 架构,然后再次部署。

使用新数据库时,请使用严格模式

如果您将 Data Connect 与新数据库搭配使用,并积极开发应用架构,并且希望确保数据库架构与应用架构完全一致,则可以在 dataconnect.yaml 中指定 schemaValidation: "STRICT"

这将确保系统也应用可选更改。

如果数据库中有生产数据,请使用兼容模式

如果您要更改包含生产数据的数据库,我们建议您在兼容模式下执行架构迁移,以确保不会丢弃现有数据。您可以在 dataconnect.yaml 中指定 schemaValidation: "COMPATIBLE"

在兼容模式下,系统只会将必要的架构迁移更改应用于您的数据库。

  • DROP SCHEMADROP TABLEDROP COLUMN 被视为可选项 语句,并且不会为您的计划生成(即使您的数据库架构也是如此) 包含未在应用架构中定义的架构、表或列。
  • 如果您的数据库表包含应用架构中未包含的非 null 列,系统会移除 NOT NULL 约束条件,以便您仍可以使用定义的连接器将数据添加到表中。

后续步骤