Allow {ANY-USER-ID} as path, and allow array items to be deleted from Firestore
[READ] Step 1: Are you in the right place?
Issues filed here should be about a feature request for a specific extension in this repository. To file a feature request that affects multiple extensions or the Firebase Extensions platform, please reach out to Firebase support directly.
[REQUIRED] Step 2: Extension name
This feature request is for extension: Delete User Data
What feature would you like to see?
That would be great if I could delete a specific {UID} from array lists of other users (myConnections).
How would you use it?
Here's an example: {UID} = "CnYycr9kn..." Query: .collection("users") .where("myConnections", "array-contains", {UID}) -> delete {UID} from all the lists.
The extension configuration could be something like this: users/{ALL-UID}/myConnections{UID}
Hey @rgtomaz, Thanks for submitting this request. I like this idea, but want to understand the use case better.
I could see this being implemented but with the limitation that there is only 1 pre-specified array field (configured in params), as Firestore ARRAY-CONTAINS queries cannot be chained. I'm not sure if there's a cost-effective way in Firestore to query for documents where any arbitrary number of arrays could contain the UID.
Would that solve your problem? Or would it have to search through all array fields to be useful?
Hi @huangjeff5, thank you very much for your feedback! I posted this request early last year, and I ended up adapting my database architecture to solve this problem. I'm now saving "myConnections" as documents instead of array items. Since Firestore arrays have limited size, this new approach worked even better to my platform.
If you want to proceed with the implementation, I will be happy to help although I no longer need it.
I've been keeping this use case in mind, and I think a better way to handle this would be to track all incoming writes to Firestore, and index all fields that have user data, by the user ID. That way when we delete the user data, we already know the data to delete, rather than needing an expensive discovery step that require many Firestore reads.
To track all incoming writes, we need Firestore team to support "**" wildcard syntax for event listeners. I'm working with the Firestore team to see if we can prioritize that, as that would be useful for a number of extensions.
Thanks for the input!
That sounds like an excellent solution! I'm sure it will benefit many users and applications! Thank you so much for sharing, @huangjeff5.
Once again, if you need any help, please let me know. Cheers.
Going to close as a solution has been found.