Question

我正在使用aggregation技术来跟踪聚合数据，例如Firestore中的文档总数等。

无论何时创建或删除article文档，我都会使用Firebase函数的触发器来更新单独文档中的聚合数据。

exports.onCreateArticle = functions.firestore.document("/articles/{articleId}").onCreate((change, context) => {
   // Increment a count & other aggregation data in a separate aggregation doc. This is done under transaction.
}

exports.onDeleteArticle= functions.firestore.document("/articles/{articleId}").onDelete((change, context) => {
   // Decrement a count & other aggregation data in a separate aggregation doc. This is done under transaction.
}

问题是我还希望有一个每周/每月计划的Firebase函数，该函数将articles的集合移到不同的集合中（例如，归档过程）。例如，此过程将删除/articles/{articleId}路径中的文章，并将其移动到/archivedArticles/{articleId}的其他路径中。

exports.scheduleArchive = functions.pubsub.schedule("every 7 days").onRun(async (context) => {
   /// move articles from `/articles/` to /archiveArticles/` and update aggregation doc at once.
}

问题在于，尽管此计划的过程更新了汇总文档并删除了文章，但对于每个已存档的文档，都有许多后续onDelete触发器被调用，并且它们不必要地尝试更新汇总文档，即已按计划完成。

计划的进程启动后，由于以下原因，我不希望触发onDelete。

在此计划的作业已经知道已存储多少文章的情况下，一次更新聚合doc（1个文档的写入容量对每个已归档的文档1个）的成本效益更高。
如果我仅依靠onDelete触发器进行聚合文档更新，则大量onDelete触发器将启动，并且从触发器到聚合文档的事务更新可能会失败。还会导致不必要的firebase函数调用。

下面是我的问题。

当我的Firebase函数删除文档时，有没有办法抑制onDelete被调用？（与用户删除文档有关）
如果我无法抑制onDelete触发，是否可以通过Firebase管理员api来区分onDelete是由用户还是函数触发的？（例如，使用传递到每个触发事件的context和DocumentSnapshot参数）。

Answer 1

否。部署功能时，它们始终处于活动状态。您可能会删除它以使其停止工作，或向其发送其他信号表明您自己构建了。
否，触发器中没有用户信息。最好的办法是让用户将UID写入文档中，以查明是谁，并确保其在安全规则中正确无误。

有没有办法抑制Firebase Functions Firestore触发器？

1 个答案: