Обновление значений в отдельных коллекциях с помощью Firestore в денормализованной БД

Question

У меня есть две коллекции:

Collection c1
-- doc1
-- -- name: "doc1Name"
-- -- position: 1
-- doc2
-- -- name: "doc2Name"
-- -- position: 2

Collection c2
-- doc1
-- -- name: "name1"
-- -- reference: "doc1Name"
-- -- position: 1
-- doc2
-- -- name: "name2"
-- -- reference: "doc2Name"
-- -- position: 2
-- doc3
-- -- name: "name3"
-- -- reference: "doc2Name"
-- -- position: 2

Если кто-то установит c1.doc2.position = 3, мне нужно обновить c2.doc2.position и c2.doc3.position до 3.

Однако Firestore не позволяет обновлять поля в зависимости от заданного условия, поэтому мне нужно перебрать все документы, принадлежащие c2, и обновить поле position, когда reference = "doc2Name". Если я использую пакетную запись или транзакцию, я не могу запросить C2 в их теле, потому что, если я это сделаю, Firestore возвращает ошибку типа " Транзакция уже завершила ." Из-за асинхронного Характер слушателей. И я не могу обновить одну из двух коллекций в обработчике завершения, потому что это приведет к тому, что БД станет непоследовательной в случае сбоя второго пакета / транзакции.

Это типичный сценарий при работе с денормализованными БД, и денормализация также довольно распространена при работе с Firestore. Есть ли какое-либо решение с Firestore, которое не подразумевает облачные функции?

Answer 1

Вы не можете атомарно обрабатывать или группировать динамические результаты какого-либо запроса. Вы должны быть в состоянии идентифицировать все документы до начала транзакции или пакета. Эта проблема возникнет независимо от того, пишете ли вы с мобильного клиента или с сервера (включая облачные функции, которые также могут обрабатывать события из вашего предполагаемого порядка).

Единственным вариантом может быть транзакция по всему содержимому обеих коллекций при условии, что они не меняют размер. Если коллекция может изменить размер в любое время, то я не думаю, что эта конкретная модель будет работать для вашего варианта использования, так как невозможно заблокировать всю базу данных, чтобы предотвратить возникновение конфликтующих изменений.