3.6 KiB
3.6 KiB
ADR-003-05: 删除操作技术选型
状态
已接受
日期
2026-02-03
背景
元数据删除是 Salesforce Metadata API 的核心功能之一。需要支持按类型和名称删除元数据，支持批量操作，并记录删除历史。 在实现过程中，面临以下关键技术选择：
- 删除接口选择：使用同步的
deleteMetadata接口还是基于文件部署的deploy(destructiveChanges) 接口？ - 批量处理策略：如何处理超过 API 限制（通常为 10 个）的批量删除请求？
- 数据持久化策略：如何存储删除历史记录？
决策
决策 1：使用同步 deleteMetadata 接口
选择方案：使用 Salesforce Metadata API 提供的同步 deleteMetadata 方法。
理由：
- 简单高效：对于常见的删除操作（少量组件），同步调用能立即返回结果，无需轮询等待，用户体验更好。
- 符合需求：需求明确要求返回
DeleteResult对象，这是deleteMetadata接口的标准返回值。 - 开发成本低：无需构建复杂的 ZIP 包或
destructiveChanges.xml文件。 - 粒度控制：支持对每个组件的删除结果进行单独处理（成功/失败）。
放弃方案：使用 deploy 接口（Destructive Changes）
- 理由：实现复杂（需构建 ZIP 包），异步执行需要轮询，对于简单的删除操作显得过于厚重。仅在需要大规模事务性删除或复杂依赖处理时才考虑使用。
决策 2：客户端分批循环处理
选择方案：在 Service 层实现分批逻辑，循环调用 deleteMetadata。
理由：
- 规避限制：Metadata API 的
deleteMetadata单次调用通常限制为 10 个组件。通过 Service 层自动分批（如每批 10 个），可以透明地支持任意数量的删除请求。 - 结果聚合：Service 层负责收集每一批的
DeleteResult，合并后统一返回给调用方，保持接口简洁。
决策 3：数据库持久化删除历史
选择方案：将删除结果持久化到 MySQL 数据库表 datai_metadata_delete。
理由：
- 审计需求：满足对元数据变更操作的审计要求，记录谁在什么时候删除了什么。
- 一致性：与项目中其他模块（如异步操作、Apex 测试执行）的持久化策略保持一致。
- 查询能力：数据库提供强大的查询能力，便于实现历史记录的分页查询和过滤。
后果
正面影响
- 响应速度快：小批量删除操作可实时反馈结果。
- 架构简单：无需引入复杂的异步任务队列或文件处理逻辑。
- 可追溯：完整的数据库记录确保了操作的可追溯性。
负面影响
- 大批量性能限制：如果是极大批量的删除（如上千个），同步循环调用可能会导致 HTTP 请求超时或执行时间过长。
- 缓解措施：建议前端限制单次批量操作的数量，或在大批量场景下引导用户使用后续可能开发的异步部署功能。
替代方案
替代方案 1：异步队列处理
- 描述：将删除请求放入消息队列，后台异步执行。
- 优点：支持高并发和大批量，不阻塞 Web 线程。
- 缺点：增加了系统复杂度（队列、消费者），用户无法立即获得结果，需要前端轮询。
- 适用场景：非实时、大规模的清理任务。