0

由于datastore模式下的cloud firestore支持所有查询的强一致性，

https://cloud.google.com/datastore/docs/firestore-or-datastore#in_datastore_mode

这可以用来检查唯一性吗？假设我有一个用户实体（顶级实体），它有一个数据存储区分配的 ID 作为键。过去，不可能在事务中通过电子邮件进行查询，因为它是全局查询。但似乎现在可以进行如下澄清的查询

Datastore 模式下的新 Google Cloud Firestore 查询说明

这是否意味着现在可以通过仅通过事务中的电子邮件属性进行索引和查询以插入用户实体来确保没有重复的用户实体？

我当前的实现是拥有一个单独的实体，该实体具有使用电子邮件的命名键，并在事务中对该实体进行基于键的查询。如果我可以通过电子邮件查询交易中的用户实体本身，我可以摆脱这种情况，并保证不会在竞争条件下创建重复的实体。

4

2 回答 2

1

经过一番研究，以下是我能收集到的全部内容。

  1. 即使数据存储模式是强一致的，仍然无法在事务中使用全局查询。
  2. 根据https://cloud.google.com/datastore/docs/concepts/entities#creating_an_entity，可以使用事务，获取并根据结果进行放置，但这只有在密钥唯一性的情况下才有可能.
  3. 谷歌云数据存储中概述了一些策略， 仅存储同一问题的唯一实体，Dan 建议“插入”而不是“放置”。起初我没有得到这个，因为 Appengine Datastore api 从来没有“插入”。但是 Cloud Datastore 客户端 API 具有允许显式插入的突变（而不是映射到 Upsert 的 put）。
  4. 由于突变支持，我可以使用相同的策略，即使用一个单独的实体（不同的种类）和映射到唯一属性（例如电子邮件）的键，但避免在事务中额外的 Get。我在电子邮件上使用 Named 键对用户实体和唯一性跟踪实体执行 tx.Mutate 并尝试插入两者。这会导致 AlreadyExists 错误，该错误可用于跟踪违规。
于 2019-10-10T04:10:43.057 回答
0

截至目前，还没有办法对 property 强制唯一性。但是，对于您正在尝试做的事情，有一些解决方法。上面链接的文章中解释了一种解决方法，另一种方法在这里。

于 2019-10-04T02:10:04.977 回答