我们不能查询事务内部的集合吗？

Question

我打算构造一个可爱的小集合查询并将其传递给.get，但是我看到文档说.get“读取提供的DocumentReference引用的文档”。

看来这意味着我们无法使用Transaction对象获取集合或查询集合。

我可以使用查询的.get（）方法而不是事务的.get（）方法查询那些对象，但是如果集合从我下面改变了，事务将以不一致的状态结束，而无需重试。

看来我在这里撞墙。我的理解正确吗？我们不能以一致的方式访问事务内部的集合吗？

Answer 1

您的理解是正确的。您必须确定要确保在交易完成前不会更改的单个文档。如果这些文档提前来自集合查询，则可以。但是想一想，如果您必须跟踪（非常大）集合中的每个文档才能完成交易，那将是多么不可扩展。

@WilGieseler因为集合不是一个可以像表一样锁定的“实体” - 它本质上完全不同。如果任意集合只是可锁定的，那么该产品就不会像宣传的那样扩展，因为滥用该锁会导致生产系统瘫痪（这显然不是这样的云产品的选择）。也就是说，如果您认为这是唾手可得的成果，请随时提交功能请求，但老实说我认为不会发生任何事情。https://support.google.com/firebase/contact/support (3认同)
我的观点是，暗示用户 OP 要求的功能本质上是不可扩展的，这不是一个公平的描述。如果 Firestore 愿意的话，他们可以允许事务锁定子集合，这将是一个有用的高性能功能，并且非常适合许多用例。我不明白为什么他们不能将集合锁实现为**一个**锁。 (2认同)
@stuckj 不，我是说 `db.collection('<COLLECTION_NAME>')` 返回一个查询对象，您可以将其传递给事务的 `get()`。查询对象不必从事务对象派生。查询对象只是如何从 Firestore 查找您想要的数据的描述（您想要什么集合？您想要什么过滤器？）。查询对象实际上不会执行任何操作，直到有人尝试 get() 它，并且事务将知道如何正确执行该操作。 (2认同)

Answer 2

您可以在事务的get()方法中运行查询（不仅仅是获取单个文档），但这仅适用于服务器执行。因此，如果您真的需要这样做（例如为了维护非规范化数据的一致性），您可以将该代码放在云函数中并利用服务器端事务