Reputation: 1652
Is there any way to specify something like "FINAL" when you execute a Firestore trigger so an app with a lot of triggers doesn't create recursive updates?
For a simple example here is a trigger that adds the created_date field to every document that is created:
exports.setCreatedDate = functions.firestore
.document('{collectionID}/{docID}')
.onCreate((change, context) => {
const patch = {created_at: Date.now()};
return change.ref.set(patch, {merge: true});
});
And another trigger that does the same when a document is updated:
exports.setUpdatedDate = functions.firestore
.document('{collectionID}/{docID}')
.onUpdate((change, context) => {
const patch = {updated_at: Date.now()};
return change.after.ref.set(patch, {merge: true});
});
Is there any built in way (I have a couple hacky workarounds already) to block the update from firing after we set the created_at time?
We are moving as much of the application logic for an enterprise app that has to scale to 100 million+ records, and cascading triggers are causing huge spikes in Firestore requests.
One obvious solution is to use single triggers, then have a stack of functions that are called, but I love the simplicity of using strictly core functionality and being able to write as many isolated triggers as we like.
Upvotes: 0
Views: 288
Reputation: 317362
Is there any way to specify something like "FINAL" when you execute a Firestore trigger so an app with a lot of triggers doesn't create recursive updates?
No.
Is there any built in way (I have a couple hacky workarounds already) to block the update from firing after we set the created_at time?
No.
You will have to write code in your function to determine if the invocation should not make any more changes, and just return early. It's common to either check to see if the change has already been made by looking at existing fields in the document.
Upvotes: 1