firebase 批量更新和 onWrite 触发器同步

Question

我在同步两个 Firebase 云函数时遇到问题，第一个对多个文档执行批量更新，第二个由其中一个文档上的 onWrite 触发器触发。

为了说明，假设我有两个文档 A 和 B（在两个单独的集合中）。

• 第一个云函数使用 Firestore WriteBatch 更新文档 A 和 B（两个文档都已成功更新）；
• 写入文档B 触发另一个云功能（使用onWrite 触发器）。该函数需要读取文档A；
• 我在第二个函数中有错误，因为它读取了旧版本的文档A（在第一个函数写入批处理之前）。

有没有办法确保onWrite 函数只有在两个文档都被写入之后才被触发？

我可以单独更新它们并等待 A 在第一个函数中写入 B 之前写入，但我想在一个事务中保持两者的更新，因为这些文档是链接的，而我没有想冒险让一个更新而没有另一个。

Answer 1

批量写入可确保自动完成写入：如果一个写入失败，则不会执行其他写入。另一方面，要回答上面的一个 cmets，批量写入并不能确保所有写入都是“瞬时的”，顺便说一下，这是一个在 IT 中难以定义的概念，恕我直言：- )。 AFAIK，批处理写入并不能确保写入不会按照它们被推送到批处理的顺序完成。

因此，如果您想在组成批量写入的所有写入完成后触发第二个 Cloud Function，您可以使用通过 Pub/Sub 触发的 Cloud Function。

具体来说，在您的index.js Cloud Functions 文件中执行以下操作：

声明一个发布消息的函数：

async function publishMessage(messageConfig) {
    try {
        const pubSubClient = new PubSub();

        const topicName = messageConfig.topicName;
        const pubSubPayload = messageConfig.pubSubPayload;

        let dataBuffer = Buffer.from(JSON.stringify(pubSubPayload));
        await pubSubClient.topic(topicName).publish(dataBuffer);

    } catch (error) {
        throw error;
    }
}

在你提交批量的Cloud Function中，批量写入完成后发布消息：

    await batch.commit();
    
    messageConfig = {
          topicName: 'your-topic',
          pubSubPayload: {
              docA_Id: '..........',  // Id of doc A
              docB_Id: '..........'   // Id of doc B
          }
    }
    await publishMessage(messageConfig);
    // ...

编写一个 pub/sub 触发的 Cloud Function 来执行所需的业务逻辑。如果需要用onWrite触发器触发相同的业务逻辑，两个函数之间共享代码

    exports.updateDocB = functions.pubsub.topic('your-topic').onPublish(async (message) => {

       const docA_Id = message.json.docA_Id;   
       const docB_Id = message.json.docB_Id;   

       await updateDocB(docA_Id, docB_Id);
       // ...
    
    })


    async function updateDocB(docA_Id, docB_Id)  {
       // ......
    }
    // Call this function from the onWrite CF

如果您想避免在执行批量写入时执行onWrite 触发的云函数，您可以通过批量写入使用唯一的云函数eventId 标记文档A 和B。如果此标志在 A 和 B 中相同，则不执行 onWrite 触发的 Cloud Function 中的业务逻辑，因为它将由 pub.sub Cloud Function 处理。

---

当然，这是基于几个假设，并且必须应对事件的流动，但它可能是一个可能的解决方案！