【问题标题】:Firestore allows the creation of two separate documents with the same ID in a collectionFirestore 允许在一个集合中创建两个具有相同 ID 的单独文档
【发布时间】:2020-08-24 16:13:53
【问题描述】:

我今天发现你可以在一个集合中创建两个具有相同 ID 的不同对象。 最初,我试图更新 ID 为 some-id 的现有文档,如下所示

const ref = this.db.doc(`collectionName/some-id`);
await ref.set(obj, {merge: true});

obj 这里是服务器上对象包含的子集。 我最初想为现有对象添加一个新属性。

我最终得到了两个具有相同 ID 的不同对象。一个是我已经拥有的旧的,另一个是我试图与现有的合并的。

Google Firestore 怎么可能允许集合中有重复的 ID? 还是我误会了什么?

【问题讨论】:

  • 不可能。请编辑问题以更具体地说明您所观察到的内容,以便我们都能就实际发生的事情达成一致。
  • 是的,你是对的。我将所发生的事情描述为一个解决方案以及如何避免它

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


【解决方案1】:

好的,我在发布问题后找到了解决方案。 我有一个表单,用户可以从中创建一个对象并选择它的 ID。

ID 输入中有一个空格,该空格未出现在 Fire 存储控制台中。这给人的印象是它们是一样的。

故事的寓意:如果您允许用户输入文档的 ID,则对您的 ID 运行 trim()。

【讨论】:

  • 更好的道德:不要让用户创建文档 ID。它极有可能是非常低效的——例如,没有很好的随机化和分布以实现良好的索引。让 Firestore 创建 ID 并将用户选择添加为文档中的字段要好得多。
  • 好吧,最终用户是不允许的。只有管​​理员需要创建具有特定 ID 的对象,以便我们以后可以直接查询它们。但是,是的,即使是谨慎的用户,人为错误也是意料之中的
  • 绝对不需要手动创建文档 ID 即可找到它,因为您可以查询任何字段。让“用户”(甚至是管理员)输入成为文档中的一个字段 - 无需向任何用户实际显示它;仅用于查询。让 Firestore 去做吧。
  • 我从来没有说过这是必要的。例如,选择 ID 作为电子邮件以避免重复是一种设计选择,然后直接以 doc('users/someEmail@gmail.com') 查询用户,它返回一个对象而不是 collections('users').where( '电子邮件','==','someEmail')
  • 同样,这并不是一个真正的设计选择 - ID 的分配对于 Firestore 如何能够扩展来说绝对是至关重要的和基础的。如果你坚持使用电子邮件作为文档 ID,我保证你会严重降低 Firestore 应用程序的性能。并且通过 Query 检查文档是否存在的效率不亚于使用 .doc()。 SO:没有好处,还有很多很多不好的后果。你为什么要坚持这样做?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-12-19
  • 1970-01-01
  • 2021-08-30
  • 1970-01-01
  • 2021-01-05
  • 1970-01-01
  • 2020-04-07
相关资源
最近更新 更多