25

Can someone explain this to me. I am working with node-firestore-backup-restore-master backup script for Firestore from github. Got it working but it only reads one document of the list of documents I have in a collection. The one it reads is in normal text the remaining are in italics and a message for the ones in italics says they don't exist and wont appear in queries.

They do exists and the associated documents and fields that appear when I query from my IOS app but not from the Node.js backup script.

Any thoughts?? Dave

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
David Mrozinski
  • 261
  • 3
  • 4

3 Answers3

24

If you create documents with sub-documents and then delete the top level document from an SDK, the delete is not recursive. So while the top-level document is gone, its sub-documents remain.

The document IDs for these are shown as italicized ids in the UI: these documents do not actually exist, but we show them so that you can navigate to the sub collections.

Since there is no document anymore, the document itself will not show up in query results. If you need to find this document in query results, you'll want to create an empty document as a workaround.

If you need to get these non-existing documents through the API, the only way to do so is by performing a collection group query on the subcollection and determining the parent documents from there.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Can you add any recommendation to deal with this scenarios? How to get thoose documents programatically (using a cronjob to delete them or reassign them)? Any thoughts would be usefull – cutiko Jan 15 '18 at 15:14
  • Yep, I faced this exact problem and fixed it by doing a recursive batch delete operation.. (On a deeper level, you could move this recursive batch delete operation to firebase cloud functions so that it runs on the cloud while your front-end app isn't affected in any way) – Raja Yogan Jan 15 '18 at 17:09
  • 1
    I don't think there's an API that gets "all document references that only have subcollections". Instead, I'd recommend the opposite approach: delete all subcollections when you delete their "containing" document. – Frank van Puffelen Jan 15 '18 at 17:14
15

This happens in two cases:

  1. if you delete documents with subcollections

  2. if you create directly something like "/collection/document(1)/collection/document(2)" instead of creating it in two steps:

    • step 1. create: /collection/document(1)
    • step 2. create: /collection/document(1)/collection/document(2)

And look like if you are in any of these cases you can not list "document(1)" which is a quite strange way of working because they don't exist as "documents" (this is way they are marked in 'italic') but they "exist" as references to subcollections.

J. Pablo García
  • 499
  • 7
  • 19
  • 1
    This is the situation I'm in: the documents were never deleted, but were created as references to other documents. As far as I'm concerned, this is a bug in Android and should be fixed. – FractalBob Apr 11 '22 at 08:22
15

In firestore, Documents shown in italics because of,

  1. delete collection or document with sub collection, sub documents.
  2. Adding collection and documents to an empty document.

The italics documents are not shown in your app, it can't fetched, only way to do this is directly specify the exact path and name of the document.

SOLUTION:

instead of adding only one collection to empty document, add one empty field in that document before adding collection.

In android I add an empty hash map to the field. but won't shown in database Here my example code:

Map<String ,Object> dummyMap= new HashMap<>();
DocumentReference df=db.collection("col1").document("doc1");
df.set(dummyMap);  // add empty field, wont shown in console
df.collection("your collection name");

The dummyMap and your collection are in same document "doc1".

K.vijaiarivalagan
  • 159
  • 1
  • 5
  • This was really helpful to know point #2 that adding collection and docs to an empty doc will have this result. Thanks! – Rich Finelli Nov 25 '20 at 11:37