Firestore efficiently inserting documents in subcollections

I’m creating a firestore document that’s not at the root level of an existing collection but somewhat deeper:

  const response = await addDoc(
    collection(
      firestore,
      'stats',    //collection
      'dayStats', //document
      'years',    //collection
      '2023',     //document
     'january',  //collection
    ),
      statData
  );

At the time of creating an event, the entire subcollection structure might not exist yet, but only a part of it.

This results in intermediary documents not being created. They are in italics and there’s a warning for them saying "This document does not exist, it will not appear in queries or snapshots".

The issue with this is that I need to be able to query for all years in day stats. E.g. the code below returns empty array instead of [2022, 2023] due to those docs being the ones in italic.

  const response = await getDocs(collection(
    firestore,
    RootCollections.Stats,
   'dayStats',
    'years',
  ));

I need to be as efficient as possible. I don’t consider a transaction acceptable here as I would triple the number of requests my app is making (GET to check whether ‘dayStats’ exists, GET to check whether ‘2023’ exists, then write, and this is the best case scenario for each and every inserted doc).

The ideal solution would be for firestore to create intermediary docs under the hood. This way I would be charged as 3 reqs only first time, and as 1 req for every other doc that falls in an existing year-month bucket. However, I understand that this is not possible.

I would hope there’s an efficient solution for this. Subcollections architecture tripling (or even more, depending on how deep the insert is) the number of reqs is a huge red flag that should be bolded in the docs and I didn’t even see it anywhere.

>Solution :

The ideal solution would be for firestore to create intermediary docs under the hood.

That won’t happen. When you write code to create a single document, no matter where it lives, only a single document will ever be created. In most cases, it would be more surprising for extra documents to be created other than the one that was requested. Missing parent documents is normal and expected in Firestore.

It’s time to consider whether or not using subcollections like this even makes sense for your use case. If your code is trying to check if a collection "exists" (which they don’t exactly, not like folders in a filesystem which must exist in order to accept files within them), then that’s likely not the right way to organize and query your data. Checking the existence of a subcollection isn’t the right way to use a subcollection.

It sounds like you actually just want to put all documents in a single collection, and put the year in a field of each document. If you want to know if there are documents with a given year (meaning that year "exists" in your documents somewhere), then just count the results of a query filtering the collection on that year value. From the documentation:

The server calculates the count, and transmits only the result, a single integer, back to your app, saving on both billed document reads and bytes transferred, compared to executing the full query.