How do I prevent updates to nonexistent nodes? - firebase

Question

I am using the REST api to PATCH nodes in my Firebase store. I would like to prevent updates to nodes that do not exist (because they were previously deleted). Right now, doing a PATCH to a nonexistent reference recreates it.
I looked into setting security rules, but newData.exists() does not discriminate between setting a new value and patching, so I couldn't figure out how to allow what I want without restricting new creations.
I can get a snapshot of the reference and check that before PATCHING, but I was hoping there was a more elegant way to do it without using two REST calls.
EDIT: some code!
My Firebase schema looks like:
requests:
rq123:
id: '123'
sender: '1'
recipient: '2'
expiration: '1234567',
filled: false,
filledDate: '',
New requests are written from a mobile client. My server can make updates to those request entries using the REST api. Using the python-firebase library, that looks like:
request_ref = firebase_root + '/requests/' + request.id
patch_data = {
'filled':'true',
'filled_date':'7654321'
}
firebase_conn.patch(request_ref, patch_data)
Given the design of my app, I'd like to only perform that patch if the request entry still exists. It's clear that I can get a snapshot and perform the check that way before patching, but that seemed awkward to me.

Answer 1

As I already remarked in the comments, there is no difference between these cases:
Writing to a database location that doesn't exist yet
Writing to a database location that doesn't exist anymore
So you will have to create that distinction in your application.
You have a few options. Not all of them apply to the REST API, but I'll mention them for completeness anyway.
Transactional update
The Firebase SDKs (for JavaScript, Java/Android and iOS/OSX) have a method called transaction, which allows you to run a compare-and-set operation.
With that operation you could
ref.transaction(function(current) {
if (current) {
current.filled: true,
current.filled_date:'7654321'
}
return current;
});
But since this method is not available on the REST API, it doesn't apply to your scenario.
Mark deleted records
Alternatively you can mark deleted records, instead of actually deleting them:
requests:
rq123:
id: '123'
sender: '1'
recipient: '2'
expiration: '1234567'
filled: false
filledDate: ''
DELETED: true
You could also delete all the other properties when you pseudo-delete the request, i.e.
requests:
rq123:
DELETED: true
Then in your security rules, you can reject the write operation when this flag is present:
".write": "data.child('DELETED').val() != true"
There are many ways to flag the record. For example it seems like in your case, the record-node will always have an id property. So you could also simply leave the record-node as a marker, but remove all its properties:
requests:
rq123: true
Since Firebase deleted nodes that don't have a value, I put true in here as the values.
With the above structure, we can only allow writes that either have an id property (which is the case when you create the request) or when an id property is already present (the PATH request from the REST API):
".write": "newData.child('id').exists() || data.child('id').exists()"
Keep a list of deleted nodes
My final approach would be to keep a list of the deleted request keys:
requests:
rq123:
id: '123'
sender: '1'
recipient: '2'
expiration: '1234567'
filled: false
filledDate: ''
deleted:
rq456: true
rq789: true
Once again, we set a dummy value of true for the deleted nodes to prevent Firebase from deleting them.
With this structure, you can reject write operations when the key you're writing to exists in the list of deleted requests:
".write": "!root.child('deleted').child(newData.key()).exists()"
Each approach has its own advantages and disadvantages, so you'll have to decide for yourself which one is best for your scenario.