If I understand correctly you want to write a value to the database if it doesn't exist yet.
With your current data structure that is hard to do, because there is no way on the database server to prevent multiple occurrences of the same value. So while you can do this on the client:
- run a query for the value, with something like
ref.child("numbers").queryOrderedByValue().queryEqualToValue("stringSavedFromMyCode")queryLimited(toFirst: 1)
- Check if the query has any results
- If not, write a new node with the value.
This may work most of the time, but has an inherent race condition between step 1 and step 3. To remove that race condition you'll need to use a transaction, which unfortunately will have to run on the entire numbers
node in your current data structure.
A better solution is to change your data structure.
If you want something to be unique within a certain scope in Firebase, you should use that as the key of the nodes under that scopes. So if you want to store unique numbers, use the actual numbers as the keys under numbers
:
numbers:
---"stringSavedFromMyCode": true
---"string2SavedFromMyCode": true
Given that Firebase stores the data as JSON, the above structure guarantees that each stringSavedFromMyCode
can only occur once under numbers
. Duplicates are impossible on the data structure level.
So the last line from your question would roughly translate to:
ref.child("numbers").child(stringSavedFromMyCode).setValue(true)
But to ensure that you only write when it doesn't exists, you'll need to still use a transaction:
- Run a transaction on
ref.child("numbers").child("stringSavedFromMyCode")
.
- If
currentData.value
is nil
.
- If it is, set the new value to
currentData
.
This runs a transaction at just the node you're trying to write. Because of this, it can also be enforced on the server with Firebase's security rules. They'd look something like this:
{
"rules": {
"numbers": {
"$number": {
".write": "!data.exists()"
}
}
}
}
These rules basically say: "you can write a node under number if it doesn't exist yet". But I definitely recommend reading the full documentation on security rules, as they're a key component of modeling and securing data in Firebase.
Also see: