Firebase RTD, atomic "move" ... delete and add from two "tables"?

Question

In Firebase Realtime Database, it's a pretty common transactional thing that you have

• "table" A - think of it as "pending"
• "table" B - think of it as "results"

Some state happens, and you need to "move" an item from A to B.

So, I certainly mean this would likely be a cloud function doing this.

Obviously, this operation has to be atomic and you have to be guarded against racetrack effects and so on.

So, for item 123456, you have to do three things

• read A/123456/
• delete A/123456/
• write the value to B/123456

all atomically, with a lock.

In short what is the Firebase way to achieve this?

• There's already the awesome ref.transaction system, but I don't think it's relevant here.

• Perhaps using triggers in a perverted manner?

IDK

---

Just for anyone googling here, it's worth noting that the mind-boggling new Firestore (it's hard to imagine anything being more mind-boggling than traditional Firebase, but there you have it...), the new Firestore system has built-in .......

This question is about good old traditional Firebase Realtime.

Answer 1

Gustavo's answer allows the update to happen with a single API call, which either complete succeeds or fails. And since it doesn't have to use a transaction, it has much less contention issues. It just loads the value from the key it wants to move, and then writes a single update.

The problem is that somebody might have modified the data in the meantime. So you need to use security rules to catch that situation and reject it. So the recipe becomes:

1. read the value of the source node
2. write the value to its new location while deleting the old location in a single update() call
3. the security rules validate the operation, either accepting or rejecting it
4. if rejected, the client retries from #1

Doing so essentially reimplements Firebase Database transactions with client-side code and (some admittedly tricky) security rules.

To be able to do this, the update becomes a bit more tricky. Say that we have this structure:

"key1": "value1",
"key2": "value2"

And we want to move value1 from key1 to key3, then Gustavo's approach would send this JSON:

ref.update({
  "key1": null,
  "key3": "value1"
})

When can easily validate this operation with these rules:

".validate": "
    !data.child("key3").exists() && 
    !newData.child("key1").exists() &&
    newData.child("key3").val() === data.child("key1").val()
"

In words:

• There is currently no value in key3.
• There is no value in key1 after the update
• The new value of key3 is the current value of key1

This works great, but unfortunately means that we're hardcoding key1 and key3 in our rules. To prevent hardcoding them, we can add the keys to our update statement:

ref.update({
  _fromKey: "key1",
  _toKey: "key3",
  key1: null,
  key3: "value1"
})

The different is that we added two keys with known names, to indicate the source and destination of the move. Now with this structure we have all the information we need, and we can validate the move with:

".validate": "
    !data.child(newData.child('_toKey').val()).exists() && 
    !newData.child(newData.child('_fromKey').val()).exists() &&
    newData.child(newData.child('_toKey').val()).val() === data.child(newData.child('_fromKey').val()).val()
"

It's a bit longer to read, but each line still means the same as before.

And in the client code we'd do:

function move(from, to) {
  ref.child(from).once("value").then(function(snapshot) {
    var value = snapshot.val();
    updates = {
      _fromKey: from,
      _toKey: to
    };
    updates[from] = null;
    updates[to] = value;
    ref.update(updates).catch(function() {
      // the update failed, wait half a second and try again
      setTimeout(function() {
        move(from, to);
      }, 500);
    });
}
move ("key1", "key3");

If you feel like playing around with the code for these rules, have a look at: https://jsbin.com/munosih/edit?js,console

Answer 2

Firebase works with Dictionaries, a.k.a, key-value pair. And to change data in more than one table on the same transaction you can get the base reference, with a dictionary containing "all the instructions", for instance in Swift:

let reference = Database.database().reference() // base reference

let tableADict = ["TableA/SomeID" : NSNull()] // value that will be deleted on table A
let tableBDict = ["TableB/SomeID" : true] // value that will be appended on table B, instead of true you can put another dictionary, containing your values

You should then merge (how to do it here: How do you add a Dictionary of items into another Dictionary) both dictionaries into one, lets call it finalDict, then you can update those values, and both tables will be updated, deleting from A and "moving to" B

reference.updateChildValues(finalDict) // update everything on the same time with only one transaction, w/o having to wait for one callback to update another table

Answer 3

There are no "tables" in Realtime Database, so I'll use the term "location" instead to refer to a path that contains some child nodes.

Realtime Database provides no way to atomically transaction on two different locations. When you perform a transaction, you have to choose a single location, and you may only make changes under that single location.

You might think that you could just transact at the root of the database. This is possible, but those transactions may fail in the face of concurrent non-transaction write operations anywhere within the database. It's a requirement that there must be no non-transactional writes anywhere at the location where transactions take place. In other words, if you want to transact at a location, all clients must be transacting there, and no clients may write there without a transaction.

This rule is certainly going to be problematic if you transact at the root of your database, where clients are probably writing data all over the place without transactions. So, if you want perform an atomic "move", you'll either have to make all your clients use transactions all the time at the common root location for the move, or accept that you can't do this truly atomically.