0

Title gives the TLDR; version of the question. But I think the details below provide a better oversight of the situation.

  • I have two collections CollectionA and CollectionB.

  • CollectionA is accessible to all users, CollectionB is local to each user.

  • CollectionB belongs to a user and consists of document clones of n documents housed in CollectionA. We create these cloned documents in CollectionB because we want user interactions, unique to the user, not to change the source found in CollectionA. In other words, the documents living in CollectionA need to be the blank slate originals in case other users someday come along and decide to interact with the documents (subsequently creating a clone of a document into their own respective CollectionB).

The question I'm wondering is what is the optimal way to write CRUD operations with the above pattern in mind. Specifically, I'm hung up on the best way to Delete a document in CollectionA and have it scan through and Delete all the matching cloned documents existing in users CollectionB. Note: Not all users may have cloned the "to-be-deleted" document, so it doesn't necessarily exist as a document on all users CollectionB collections.

My previous thought was to create a subcollection on CollectionA, specifically: CollectionA/{DocumentID}/CurrentUsers/{UserID}. Whenever a new user decides to clone a document they get appended to the CurrentUsers subcollection. Then, later if we decide to delete the document from CollectionA we can first iterate through that subcollection of UserIDs, then with each ID find the matching User, and delete the matching CollectionB cloned document (I figure they can share the same ID).

My concern with that approach is if 3,000 users have cloned this document, that first READ of the CurrentUsers would be 3,000 reads. I figure returning 3000 documents is a very large query. Obviously, it only gets worse if we scale up to 30,000 maybe worst case 3,000,000 users (am I close to a problem involving 3 million users? Not at all. But, I'd prefer to write a solution that scales well the first time!)

It feels like a good practice to write the UserIDs of users to the A document's CurrentUsers subcollection. Though, this hinges on there being a way for me to simply iterate through the IDs of each of those documents to then find a matching User and delete their cloned copy. But, I don't know. Is there a better way to do this?

Thoughts?

-- hopefully that example made sense.

kevin
  • 2,707
  • 4
  • 26
  • 58
  • 1
    "is there a way to iterate through document_ID's without having to read?" Nope. While with the server-side SDKs and REST API you can [request an empty projection](https://stackoverflow.com/questions/47061903/how-to-get-a-list-of-document-ids-in-a-collection-cloud-firestore/47064719#47064719), and that way read only the document IDs, you'll still be charged a document read for each ID you read this way. – Frank van Puffelen Oct 23 '20 at 01:59
  • @FrankvanPuffelen honestly, I think I'm just pinching pennies here. I could create a shallow delete where I just delete the `CollectionA` document, which would probably be fine. Or in rare cases, do the 'deep delete" where I go through all that work mentioned above and delete the sh*t out of that document. Thanks for the link though, kudos! – kevin Oct 23 '20 at 02:17

0 Answers0