5

Firebase Realtime Databaseでクラウド機能を使用する場合、クラウド機能を使用して特定のフィールドをターゲットにすることができます。たとえば、このJSON構造では、user1のメールフィールドが('/user/{userId}/email').onUpdateのクラウド関数で変更されたときにターゲットを設定できます。 Firestoreと今Firebase - クラウド機能を使用した特定のFirestoreドキュメントフィールドのターゲティング

{ "user": { "user1": { "name": "John Doe", "phone": "555-5555", "email": "[email protected]" } } }

私が特定のフィールドをターゲットにすることはできませんと文書のみをターゲットにすることができているようです。この場合、電子メールフィールドを対象とするFirestoreのクラウド機能は、('/user/{userId}').onUpdateのようになり、userコレクション内の文書が変更されるたびに発生します。これは多くの浪費された雲の機能を発火させるでしょう。これはFirestoreの仕組みですか、そこにはエレガントな作品がありますか?

答えて

4

データモデルが異なるため、正しいです。Cloud Firestoreでは、フィールドレベルではなくドキュメントレベルのイベントでクラウド機能をトリガすることしかできません。

電子メールを別のドキュメント(たとえば電子メールと呼ばれるサブコレクション)に格納する方法の1つは、電子メールを更新することは起動する変更のみです。これはあなたが電子メールを必要とするたびに余分な文書を読む必要があります。

もう1つの同様の方法は、同じドキュメント内にそれを残しておくことですが、関数をトリガーする2番目の書き込みとしてサブコレクションに書き込むこともできます。電子メールをドキュメントとして使用して、ドキュメントにタイムスタンプフィールドを追加して、古いドキュメントを簡単に削除できるようにします(削除する最も古い電子メールドキュメントを関数内で選択してください)

+1

サウンドはwork-円形。私はフィールドでトリガーがすぐに可能になることを願っています。 – BushJopie

+0

Realtime DatabaseはCloud Firestoreと並んで使用できます。おそらく、リアルタイムデータベースにクラウド機能をより正確にトリガーする必要があるデータリソースを配置することは、解決策になる可能性があります。個人的に私は過剰な関数呼び出しが問題ではないことを発見しました。 Firebaseは寛大な量を与え、かなり安くスケールする。しかし、すべてのアプリは異なっています。 –

関連する問題