Firestore规则,原子写入和写入限制

时间:2019-08-18 07:19:07

标签: firebase google-cloud-firestore firebase-security

关于Firestore规则评估,我有一个分为两部分的问题。这些部分是相关的,这就是为什么这里只有一个问题...

第一部分-原子写访问权限

让我们说我有一个写规则,例如

allow write: if resource.data.claimedBy == null && request.data.claimedBy == request.auth.uid;

这个想法是,任何用户都可以对此资源提出要求。但是,如果一次将此资源提供给所有1000个用户,而他们又跳起来提出主张并同时进行.update()调用,该怎么办?

这将是第一个成功的方案吗? Firebase将为第一个用户(获胜者)设置字段,然后其他人将拒绝他们的写入,因为由于获胜者写入中存在值而导致规则失败。还是存在任何可能导致竞争状况的风险,并且价值在某种程度上暂时是一回事,然后又变成另一回事了?

我觉得规则会禁止比赛条件,但我不确定。

第二部分-写入限制

好的,所以这部分是从第一部分开始的。 Firestore对单个文档的写入限制通常为1个写入/秒。假设第一部分以我希望的方式工作,其他999个用户将得到拒绝写入的信息。这些拒绝是否因为发起了写而计入1个写/秒的写限制,还是因为规则禁止实际写而不计入?

很明显,将所有这些索取尝试一次计为1000次写入对于1次写入/秒限制是不利的。

我在这里假设,但是我认为它不会计入该限制,因为我的理解是该限制是由底层存储机制的性质决定的,并且规则阻止了拒绝时进入该层。但同样,我不确定。

第三部分-奖励部分

就帐单而言,被规则拒绝的写入是否仍算作“写入”?我知道对不存在的文档的查询(实际上没有文档被读取)仍然算作一次读取,因此我想知道是否针对禁止基本写入的规则进行类似写入并产生费用。 / p>

非常感谢您!

1 个答案:

答案 0 :(得分:0)

您应该使用transaction来避免和阻止并发写入。事务可以检查该文档是否先前已被声明,然后中止。

如果写入被规则拒绝,则不会计入任何写入限制或记帐,因为文档中的实际数据都没有更改。