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.
Related
This is my first time using a NOSQL database and I'm really struggling to work out how to structure my data.
I have an app that predicts a users mood and then the user can select if that's right or not. So I need to save both the prediction and the actual result. I want to be able to pull the latest result from firebase and display it on the app.
I understand how I'd do this on an SQL DB and understand how to write an SQL query to get that data back out.
For my Firebase DB I thought of the following structure
the document name is the usersID and store multiple arrays based on the timestamp but I can't seem to user OrderBy on a document only a collection so not sure how to get this back.
The fact that this seems so difficult less me to believe I've implemented the DB wrong to begin with.
Structure of DB is as follows:
I should add that it all works fine for the USER_TABLE as its one document id and a single entry, so I've no problem retrieving that.
Thanks for your help!
orderBy is an instruction to the database to order documents on the server, before it returns them to your app. To store the fields inside the document, you can just do that inside your application code after it receives the document(s).
There is in itself nothing wrong with storing these entries in a single document, Just keep in mind that:
A document can be at most be 1MB in size, so make sure this fits your maximum number of entries.
Firestore only ever returns full documents, so you will either get all entries in a document, or none of them.
You won't be able to order or filter the entries inside a single document. If that is a requirement for you, consider storing each entry in its own document in a subcollection. Note that this will increase the number of documents each user reads though, which will increase the cost.
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.
I have a few music albums - basically just files in folders - that I want to upload to Firebase Storage.
One would usually run a function after a file has been uploaded to create a Document containing the metadata about the Song but that's where Im stuck.
I can get most infos I need by reading the Tracks ID3 Tags but in a NoSql Database I think im supposed to not only create a Document for the Track but also a Document for each album with an array of all tracks - or at least an array with all track ids.
But when or how do I create the Album Document? Another example is the Album Cover.. I want to save the Url inside the Track Document as well as in the corresponding Album but that means that the Artwork is the first thing I need to upload because I can't add an URL because it doesn't exist yet.
I feel like I have to get this right before I start because updating everything afterwards is a pain.
Is using upload functions really the way to go here or is there really a tool or another way im missing.
thank you very much
You mentioned Firebase Storage wich is a just a cover for Cloud Storage and it's a obejct managment system not a Database, however I think you are refering to Firebase Firestore.
On firestore since as you mentioned is a NoSQL DB and the schema structure your Db should have, There no correct way to do this and will defitetly depend on each specific use case. However you can take a look at this docs where it's expalined how to arquitecture your schema thinking from a SQL to a NoSQL format.
Among other information the main pointsa are:
In general, you can treat documents as lightweight JSON records
You have complete freedom over what fields you put in each document
After you create the first document in a collection, the collection exists. If you delete all of the documents in a collection, it no longer exists.
You can use sub collections inside of collections
Deleting a document does not delete its subcollections!
And finally to have an idea on how to structure the information, you can take a look at this repo where "NoSQL-Spotify by Luke Halley" explains a NoSQL schema based on spotify so I think it shoudl fit your need or at least give you a starting point.
I read some answers here on stackoverflow, were is said that every time we get documents from Firestore, the SDK is always trying to get the online version of the documents, even if no documents were changed. This is ending in having more reads billed, which in my opinion is not necessary, since nothing is changed.
What I want to achieve
Let's say a have a collection of 5 documents. When the user opens the app for the first, I want to pay 5 reads. However, when the user opens the app for the second time, I just want to pay a read operation only for documents that were changed. If nothing is changed, I don't want to pay any reads, I just want to read the data from cache. Is this possible?
The key phrase in your question is:
If nothing is changed, I don't want to pay any reads,
To determine if something changes about the documents in your cache, the Firestore server will need to read those documents. And hence you will pay for those reads.
The only way to work around this, is to take control of filtering the changed documents yourself.
For example, if you include a lastModified field in each of your documents, you can use that to retrieve only the new/modified documents from the server, and then run your other read operations against the local cache by specifying source options.
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.