When a collection is deleted from Cloud Firestore, its indexes are deleted along with it. I presume that when a collection goes from one or more documents to zero documents that its indexes are preserved. However, in the Cloud Firestore UI, when a collection goes from one document to zero the collection disappears from the root collections tree. Again, I presume this is an artifact of the Cloud Firestore UI, but it got me wondering whether something more happens when a collection becomes empty (as opposed to the collection being deleted outright).
Can you please help clarify what happens (if anything) when a collection goes from one or more documents to zero in Cloud Firestore? Do I need to be worried about losing any indexes when this occurs?
I'm neither Googler nor Firebaser, BUT...
Firestore indexes documents, not collections - the collection paths are an organizing principle more than physical entities. The "collections" are part of the path to documents, and it's the paths and the document fields that end up indexed.
Case in point: you can actually delete a collection while child documents remain, and they will still be indexed with the collection name/ID as part of their path - you'll see this in the console with the collection (and any interstitial document) names italicized.
When a collection goes from 1 to 0 documents, all that happens is that the document is gone, and nothing else. The UI sees no reason to display a collection when there is nothing to show.
Collections don't really "exist". They are just ways to organize documents for the purpose of making queries. What you see in the console is just there to help you visualize the contents of the database. Collections will apparently spring into "existence" when a document is first created, and just as quickly disappear when there are none. They do not work like directories in a filesystem.
An index is just a way of telling Firestore that you have special query needs for documents in a certain named collection or collection group. The index simply enables the query against the documents in the collection or collection group that you name. The index works without requiring any documents to index, and it will continue working no matter how many documents exist.
Some great answers by LeadDreamer and Doug already, but one more thing you seem to be curious about: deleting all documents from a collection does not affect the index definitions for that collection. So if you later add documents to the collection again, the same index definitions will still apply.
Related
I read in this question that empty documents will be deleted in Google Firestore.
Is this still true? I have empty documents in one of my collections, they've been there for months, so I guess is not true (anymore).
Can anyone enlighten me?
Nope, there is nothing in place to automatically delete empty documents, as you might have a valid reason for wanting those empty documents to exist.
That said, I'd typically recommend putting a dummy field into a document that you create, even if you have no use for that field. The reason for that is that some tools may reject empty documents or not store them. But there's nothing on the database itself that does this, and I can't even call out any of such tools at the top of my head right now.
I have an onRequest cloud function which inserts an item into my firestore instance:
...
db.collection('game').doc(game_id).collection('board').doc(board_id).add(new_piece)
...
If game_id doesn't exist in my database, the doc new_piece is still inserted, presumably under orphaned game and board collections (they show up italicized and slightly faded in firestore console).
This seems to be standard behavior. However, if I want to reject creation of documents if their parent path doesn't exist, what is the best way to do so?
One obvious way is to first check the existence of game and board collections. However, that adds additional latency and more .then blocks (I don't want to think in terms of monads here!). Is this the recommended way?
Is there a way I can simply instruct firestore to not create orphaned docs and collections in a given insert path and return an error (to be handled by the caller)?
No, it's not possible. If you want to know if something exists, you will have to make queries for it.
In Firestore, I plan the schema for each collection by writing it by hand. If I have 500 dummy records in a single collection, I would like to delete all documents except for one, because when I delete an entire collection, the schema disappears.
Is there a way to delete every document in a collection but leave one behind? Or, to copy a document to a new collection so I can delete the old one?
Firestore is "schemaless". There is nothing except your own code enforcing the names and types of fields in a document. Each document could be completely different.
Also, you might want to know that a collection will spring into existence the moment a document is written to it. So, even though a collection doesn't appear to exist when you load the console, that doesn't stop documents being written to it.
Lastly, there is no single operation that can delete an entire collection except one document. You would have to write code to query all the documents and delete them all individually except the one you want to preserve. But, based on the things I just said above, that doesn't seem to have the value the you might think.
I am currently in testing mode, and I keep changing my structure. The problem is that every time I want to try something new I need to manually delete each collection by typing it's name, which takes forever.
Also, I know that deleting a collection deletes its documents, but deleting a documents doesn't delete its subcollections.
I have a few documents with suncollections and when I delete them, i don't see the subcollections anymore? Where are they? Are they lost in some database vortex taking space on my allocated disk forever now?
If you delete a document but not its subcollections, the subcollections still exist and you access them exactly like you would normally. The document ID will appear in the console in italics to indicate that there's no document present, but there are subcollections organized under the ID.
There is currently no way to wipe out a Firestore database, other then to delete all the document using the normal ways that you would do so. Delete them in the console, or delete them by querying for them, iterating the results, and deleting each document.
The firestore docs say:
When you delete a document that has associated subcollections, the subcollections are not deleted. They are still accessible by reference. For example, there may be a document referenced by db.collection('coll').doc('doc').collection('subcoll').doc('subdoc') even though the document referenced by db.collection('coll').doc('doc') no longer exists.
Since deleting collections is not recommended from a web client, it seems the easiest thing to do in that case would be to delete the document and leave the orphaned subcollection.
Are there any negative impacts to leaving lots of orphaned subcollections in your database?
Yes there are negative impacts of leaving orphaned collections in your database.
First, that is space you've already wasted. You'll just end up exceeding your quotas or budgets faster.
Secondly, bad queries - you can end up with a query, lets say, you want to filter all documents by a condition on a property of documents in different sub collections. That would include your orphaned sub collections too. This is inefficient both performance-wise and cost-wise.
Moreover, I am not even sure how that would impact any index you want to create. In general, leaving orphaned entries in a nested document database is a bad idea, especially if it is not at the leaf level of your structure.
Easiest thing to do - Create a cloud function that cleans up all your orphaned sub collections. You can always call that from the client in turn.