1
votes

Why don't triggers fire when a parent is removed? Need a firebaser to explain why it was implemented this way. Here's an example:

Trigger function on ref: ref('/users/{user_id}')

Trigger fires with: firebase database:set {'/users/123': someval}(pseudo code)

Trigger fires with: `firebase database:remove '/users/123'

Trigger doesn't fire: firebase database:remove '/users'

I would expect that last parent remove statement to fire the trigger since it's removing child data. If there were two users in that node I would expect it to fire twice. I understand I could put another trigger on /users and loop through the children. But why did you guys implement triggers this way? Just curious. Still think functions are awesome BTW. Thanks.

2
And then how about a firebaser with a high stack overflow reputation create a firebase-cloud-functions tag. Doesn't seem like there is one. - prozac
After playing around with it more, putting a trigger on the parent is definitely super easy. I still find it inconsistent that the child trigger doesn't fire when the parent is deleted. But the implementation is probably correct. So that the programmer doesn't have to deal with the parent trigger and child trigger firing at the same time. - prozac
FYI the product is called "Cloud Functions for Firebase". There's no such thing as "Firebase Cloud Functions". Cloud Functions is a product of the Google Cloud platform, and Firebase users have additions to that for Firebase-specific features. - Doug Stevenson

2 Answers

0
votes

There are several events available that exhibit the same behavior... in Swift we have

.childAdded
.childChanged
.childRemoved

.value

If you notice the names of the events start with .child, and you are correct they only fire on child nodes being added, changed or removed. The real-time database behaves like the cloud triggers.

However, .value (on the parent node_ is the one you are looking for as it will fire when the parent node is created or removed. Of course when removed, the snapshot (or event data) will be nil, but it does in fact fire.

As a test, here's some Swift code that watches a parent node called... parent_node.

 let nodeRef = self.rootRef.child("parent_node")

 nodeRef.observe(.value, with: { snapshot in
       print(snapshot)
 })

When parent_node does not exist and is added, the event fires just like a trigger. In this instance I added a child node name = larry. This is the event firing and printing the contents of the snapshot event

Snap (parent_node) {
    name = larry;
}

Then I removed the parent_node, which also fires like a trigger since it's the parent node we are interested in, and this is the result

Snap (parent_node) <null>

So the bottom line is that child observers only fire for child events but parent value observers fire for everything.

0
votes

Yea looks like a duplicate of Cloud Functions for Firebase onWrite trigger not called when parent is deleted

I hate it when I search and still can't find it when someone else answers the same question.

If any firebaser reads this, it would still be helpful see a tag for "Cloud Functions for Firebase"