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 项架构迁移有两个不同的架构验证 模式:strict 和 compatible。
严格模式验证要求数据库架构与 然后才能更新应用架构不限 您的 Data Connect 架构中未使用的表或列 都将从数据库中删除
兼容模式验证要求数据库架构兼容 然后才能更新应用架构;任意 删除架构、表或列的其他更改是可选的。
兼容意味着架构迁移仅影响表和列 在应用架构中引用。数据库中未被应用架构使用的元素会保持不变。因此,部署后,您的数据库可能包含未使用的:
- 架构
- Tables
- 列
连接器部署
Data Connect 查询和更改操作不是由客户端代码提交并在服务器上执行的。相反,在部署时,这些 Data Connect 操作会存储在服务器上,例如 Cloud Functions。这意味着部署可能会中断现有用户。
遵循部署工作流
您可以在本地项目目录和 Firebase 控制台中处理 Data Connect 项目。
推荐的部署流程包括:
- 列出当前部署的架构和连接器:
firebase dataconnect:services:list
。 - 管理任何架构更新。
- 使用
firebase dataconnect:sql:diff
检查 Cloud SQL 数据库与本地 Data Connect 架构之间的 SQL 架构差异。 - 如果需要,请使用
dataconnect:sql:migrate
执行 SQL 架构迁移。
- 使用
- 通过运行
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 SCHEMA
、DROP TABLE
和DROP COLUMN
被视为可选项 语句,并且不会为您的计划生成(即使您的数据库架构也是如此) 包含未在应用架构中定义的架构、表或列。- 如果您的数据库表包含应用架构中未包含的非 null 列,系统会移除
NOT NULL
约束条件,以便您仍可以使用定义的连接器将数据添加到表中。
后续步骤
- 部署和管理使用生成的 SDK 开发的客户端代码的步骤如下: Android iOS、Web 和 Flutter。
- 如需详细了解部署工具,请参阅 Data Connect CLI 参考文档和 Data Connect 配置文件参考文档。