【问题标题】:Firestore: handling concurrency with booking appFirestore:使用预订应用程序处理并发
【发布时间】:2021-04-20 11:15:31
【问题描述】:

我目前有一个 bookings 和一个 bookable 集合。 bookings 中的每个文档都包含一个日期范围(check-outcheck-in)以及对 bookable 文档的引用数组。

对于如何保证同一 bookables 的两个重叠 bookings 不会同时写入,我感到有些困惑。据我了解,我不能通过交易之类的方式technically lock a collection,所以我想知道我的选择是什么(也许重组我存储数据的方式等)。

任何指针或建议将不胜感激。

编辑:

假设用户 A 想要预订与 用户 B 相同的两个项目,并且时间范围相同。他们几乎同时加载预订 UI 并确认他们的选择。

在为每个请求在 bookings 集合中创建新文档之前,应用程序将执行 get 查询以检查是否存在任何重叠,如果不存在则插入新的预订文档。应用程序检查booking 集合中的重叠和创建新文档之间的那部分时间似乎打开了一个不一致的窗口(例如,可能允许创建两个具有重叠时间范围和项目的文档)。

事务是否可以根据集合中符合特定条件的其他文档的存在来帮助防止将新文档写入集合?

【问题讨论】:

  • 您的选项位于firebase.google.com/docs/firestore/manage-data/transactions。如果您很难完成这项工作,请分享一个特定的用例,展示您已经在代码中尝试过的内容以及失败的地方。
  • 谢谢@FrankvanPuffelen,也许你是对的。我更新了帖子,更详细地解释了我的疑问。

标签: database google-cloud-firestore concurrency locking


【解决方案1】:

为防止用户意外覆盖彼此的数据,您需要use a transaction

为防止用户故意覆盖彼此的数据,您需要use security rules。这样做的关键是使用您希望唯一的信息作为文档的 ID。

假设您通过日期和开始时间来识别时间段,您可以有一个文档 ID "20210420T0900"。如果用户在该文档已经存在时尝试写入该文档,您可以在数据库的安全规则中拒绝该写入。

【讨论】:

  • 谢谢弗兰克。如果预订的唯一性由时间范围和预订项目(ID)组成,那么也许我需要重新考虑我的数据库结构,嗯?我最初曾尝试将预订保留为每个项目下的嵌套集合,但发现这很奇怪,因为每个嵌套预订都有自己的 ID,但您的回答让我想到重新审视这种方法,并可能将时间标识与用户 ID 一起用作嵌套预订文档ID,然后在 UI 端将预订“合并”为一个,以表示多个项目的一个“大”预订。
  • 您可以在文档 ID 中包含项目 ID。听起来您希望每个项目都有一个单独的预订文档,因此结合批量写入/事务以确保预订中的所有项目都以原子方式写入安全规则,以防止用户故意覆盖彼此的预订。一切皆有可能,因此,如果您在实现它时遇到问题,我建议您打开一个新问题,其中包含您尝试过的代码和数据,并调试出了问题的详细信息。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2010-11-12
  • 1970-01-01
  • 2017-10-15
  • 2019-04-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多