Question

In doing a bit more programming with Firebase today, I found myself wishing for a couple of features:

1) Merge set:

Say I have a firebase ref that has the value {a:1,b:2,c:3}.

If I do something like ref.set({a:-1,b:-2}) the new value will (unsurprisingly) be {a:-1,b:-2}.

Instead, imagine ref.mergeSet({a:-1,b:-2}) which would have a result in the value of the ref being {a:-1,b:-2,c:3}.

Now, I realize that I could do something like ref.child("a").set(-1) and ref.child("b").set(-2) to achieve this result, but in at least some cases, I’d prefer to get only a single call to my .on() handler.

This segues into my second idea.

2) Batch set:

In my application I’d like a way to force an arbitrary number of calls to .set to only result in one call to .on in other clients. Something like:

ref.startBatch()
ref.child("a").set(1)
ref.child("b").set(2)
....
ref.endBatch()

In batch mode, .set wouldn’t result in a call to .on, instead, the minimal number of calls to .on would all result from calling .endBatch.

---

I readily admit that these ideas are pretty nascent, and I wouldn’t be surprised if they conflict with existing architectural features of Firebase, but I thought I’d share them anyway. I find that I’m having to spend more time ensuring consistency across clients when using Firebase than I expected to.

Thanks again, and keep up the great work.

Answer 1

UPDATE: We’ve added a new update() method to the Firebase web client and PATCH support to the REST API, which allow you to atomically modify multiple siblings at a particular location, while leaving the other siblings unmodified. This is what you described as “mergeSet” and can be used as follows:

ref.update({a: -1, b: -2});

which will update ‘a’ and ‘b’, but leave ‘c’ unmodified.

---

OLD ANSWER

Thanks for the detailed feature request! We’d love to hear more about your use case and how these primitives would help you. If you’re willing to share more details, email [e-mail] and we can dig into your scenario.

To answer your question though, the primary reason we don’t have these features is related our architecture and the performance / consistency guarantees that we’re trying to maintain. Not to go too deep, but if you imagine that your Firebase data is spread across many servers, it’s easier for us to have stronger guarantees (atomicity, ordering, etc.) when modifying data that’s close in the tree than when modifying data that’s far away. So by limiting these guarantees to data that you can replace with a single set() call, we push you in a direction that will perform well with the Firebase architecture.

In some cases, you may be able to get roughly what you want by just reorganizing your tree. For instance, if you know you always want to set ‘a’ and ‘b’ together, you could put them under a common ‘ab’ parent and do ref.child('ab').set({a:-1, b:-2});, which won’t affect the ‘c’ child.

Like I said, we’d love to hear more about your scenario. We’re in beta so that we can learn from developers about how they’re using the API and where it’s falling short! [e-mail] 🙂