Not allowed duplicate record - firebase

Question

It's a simple check to restrict duplicate entries, i can't find a way to do it, thought.
Shema:
{
"languages": {
"unique_id": {
"code": "Fr",
"name": "French"
},
"unique_id": {
"code": "En",
"name": "English"
}
}
}
Security rule that i've tried:
service cloud.firestore {
match /databases/{database}/documents {
match /languages/{language} {
allow write: if !(resource.data.hasAny([request.resource.code]));
}
}
}
For instance :this must not allowed
{
"languages": {
"unique_id": {
"code": "Fr",
"name": "French"
},
"unique_id": {
"code": "En",
"name": "English"
},
"unique_id": {
"code": "Fr",
"name": "German"
}
}
}

Answer 1

There really isn't a good way to do it with the current schema. Below are 2 methods with different trade-offs you could explore.
Invert Data Model
Change your data model to make uniqueness the only option, which removes the need to validate.
{
"languages": {
"Fr": {
"name": "French"
},
"En": {
"name": "English"
}
}
}
Note in this model it isn't possible to add your broken case.
To query for any document with a particular language code, e.g. 'En', you can do:
.where("En.name", ">", "")
Pros:
Non-unique language codes are impossible
Simple to implement
Cons:
You won't be able to do composite indexes on language code or name
Post-validation
Alternatively, you can set up a Cloud Functions to trigger on any writes. This Function can then have code to do the uniqueness enforcement for you. It would then follow some logic you define if it detects an issue, such as either flagging the document as bad or removing & logging the subsequent non-unique entries.
Pros:
You can do composite indexes with languages.unique_id.code and languages.unique_id.name
Cons:
Incorrect data can exist for short periods of time
Harder to give errors back to the client
Post-Update
Rather than allowing clients to update the language codes, require them to write to a subcollection. Have Cloud Functions trigger on update to the sub-collection, then update the master document if it pasts your checks. Optionally you can then delete the document in the subcollection or leave it as an audit trail.
Pros:
You can do composite indexes with languages.unique_id.code and languages.unique_id.name
Document will always be correct
Cons:
Data in the document can be stale for short periods of time
Harder to give errors back to the client