# #firebase #google-cloud-firestore #google-cloud-functions
Вопрос:
Я использую метод агрегирования для отслеживания агрегированных данных, таких как общее количество документов и т. Д. В Firestore.
Всякий article
раз, когда документ создается или удаляется, я использую триггер функций Firebase для обновления данных агрегации в отдельном документе.
exports.onCreateArticle = functions.firestore.document("/articles/{articleId}").onCreate((change, context) => {
// Increment a count amp; other aggregation data in a separate aggregation doc. This is done under transaction.
}
exports.onDeleteArticle= functions.firestore.document("/articles/{articleId}").onDelete((change, context) => {
// Decrement a count amp; other aggregation data in a separate aggregation doc. This is done under transaction.
}
Дело в том, что я также хочу иметь еженедельную/ежемесячную запланированную функцию firebase, которая перемещает набор articles
в другую коллекцию (например, процесс архивирования). Например, этот процесс удаляет статьи в /articles/{articleId}
пути и перемещает их по /archivedArticles/{articleId}
другому пути.
exports.scheduleArchive = functions.pubsub.schedule("every 7 days").onRun(async (context) => {
/// move articles from `/articles/` to /archiveArticles/` and update aggregation doc at once.
}
Проблема в том, что, хотя этот запланированный процесс обновляет документ агрегации и удаляет статьи, onDelete
для каждого заархивированного документа вызывается множество последующих триггеров, и они без необходимости пытаются обновить документ агрегации, который уже выполнен запланированным процессом.
Когда начнется запланированный процесс, я не хочу onDelete
, чтобы он запускался по следующим причинам.
- Гораздо более экономично обновлять документ агрегации сразу (1 емкость для записи документа против 1 на каждый архивированный документ), когда это запланированное задание уже знает, сколько статей было заархивировано.
- Если я буду полагаться только на
onDelete
триггер для обновления документа агрегации, появится большое количествоonDelete
триггеров, и транзакционное обновление от триггера до документа агрегации, скорее всего, завершится неудачей. Это также приведет к ненужному вызову функций firebase.
Ниже приведены мои вопросы.
- Есть ли способ
onDelete
предотвратить вызов, когда мои функции firebase удаляют документы? (против пользователей, удаляющих документ) - Если я не могу подавить
onDelete
триггер, есть ли способ отличитьonDelete
, был ли он вызван пользователем или функциями через api администратора firebase? (например, с использованиемcontext
DocumentSnapshot
параметровamp;, которые передаются в каждое событие триггера).
Ответ №1:
- Нет. Функции всегда активны, когда они развернуты. Вам пришлось бы удалить его, чтобы он перестал работать, или послать ему какой-то другой сигнал, который вы создаете сами.
- Нет, информация о пользователе недоступна в триггере. Лучшее, что вы можете сделать, — это попросить пользователя записать свой UID в документ, чтобы узнать, кто это был, и убедиться, что он соответствует правилам безопасности.
Комментарии:
1. Спасибо. Мне удалось найти обходной путь. Я добавил произвольное свойство в каждый документ, прежде чем удалить их. Когда
onDelete
срабатывает, я мог бы сначала проверить, существует ли добавленное свойство, и пропуститьonDelete
логику, если это так. Это было возможно, потому что триггеры Firebase Firestore предоставляютsnapshot
информацию о документе, который был удален в дополнение кcontext
.2. Я применил то же самое решение. Хотя это немного запутанно, так как иногда он вызывает более 30 триггерных функций.. Пустая трата ресурсов 😉 Было бы неплохо иметь возможность пропустить функцию триггера (например:
admin.firestore({skipTriggers: true})...