This question already has answers here:
Document Updates - Do updates with no changes still cost 1 write?
(2 answers)
Closed 2 years ago.
Im trying to find out how firebase is billing write operations. In the billings documentation I could not find a clear definition of when a write is counted. Lets say I run a set query with the exact same data of the original documen, such that the document won't be affected, will this be billed as a write operation?
When I run my query with the console open nothing happens, and i was just wondering if these writes do also count.
When you write data, the server doesn't check if the data you write is the same as what already exist. Instead: it writes the data you provide. Hence: writing the same data is still counted as a write operation.
I find it easiest to understand the billing for Firestore by thinking of it as reads from/writes to a disk. When you tell a disk to write a file, it writes that file.
Related
This question already has an answer here:
If one of the object to be written has the same content as the one in Firestore, what will happen?
(1 answer)
Closed last year.
Data in Firestore:
Now suppose if I perform a write operation without updating any data, will it increment the write count in Firestore?
I just ran a quick test writing the same value to the same document at an interval, and the usage panel in the Firebase console showed an increase in writes for each write call.
This question already has answers here:
Does updating one field will download the whole document from the database or just update local version?
(1 answer)
Only retrieve changed document field
(1 answer)
Closed 2 years ago.
I have a question about the bandwidth / data usage of a Firestore listener.
I know Firestore will only give the updated documents once it's listening.
Let's say a single document is 0.3 mb. If it gets updated frequently, does the listener has to download the document (0.3 mb) every time or will it only download the "new/updated" data.
This would make a difference for the end-user who is maybe using 4g.
I use Flutter in combination with Firestore.
Thanks!
Every time a document is updated from an active listener, the entire contents of the document are transferred with each update. It does not transfer only the fields that changed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm doing a fair bit of work on a set of Firestore collections and documents. It amounts to a good amount of writes and reads, as I'm setting two-way refs and whatnot. Multiple documents are being written to multiple times.
Since Firestore offers offline capability, is it possible to reduce the number of writes via preparing all the data locally, then sending it to the server?
I'm using the Admin SDK.
It depends on what you mean. One document write is always going to cost one document write, no matter when or how that document was written. Batch writes don't in any way reduce the number of documents written, they just make all the document writes take effect at the exact same moment in time.
If you're staging lots of changes to a single document to take effect later, then feel free to do that. Just write the document whenever you've figured out what final document looks like, and no sooner.
I'am moving away from google appengine standard Python 2.7 NDB to Svelte, Firestore and RxFire.
I was able to dramatically reduce the number of reads and writes by batching hundreds of appengine NDB entities (datastore / data objects) into a single document using a data object map.
Every data object has a batchId prop to optimize (batched) batch writes / document writes. (batchId = docId)
Most of the querying is now done in the client using filters. This resulted in very simple reactive Firestore queries using RxFire observables. This also dramatically reduced the number of composite indexes.
doc:
batchId: docId
map: data Objects
batchId: docId
other props ...
....
I also used maps of data objects for putting all kinds of configuration and definition data into single documents. This setup is easy to maintain and available with a single doc read. The doc reads are part of observables to react to doc changes.
This question already has answers here:
How do you force a Firestore client app to maintain a correct document count for a collection?
(2 answers)
Closed 3 years ago.
I need to limit the number of documents a user can have in a collection.
I expect that having a limit of let's say 100 documents when a user tries to create the document 101 gets an error.
Is there a way of doing this using firestore security rules ?
Security rules don't have the capability to count the number of documents in a collection. In fact, counting documents in Firestore is, in general, is kind of a difficult problem that typically requires some support from a product like Cloud Functions.
If you want to get something like this to work, you will have to write some Firestore triggers in Cloud Functions that manages the count of documents by triggering some code when a document is created or deleted. This count would have to be stored in another document in another collection. Then, the contents of that document could be used in security rules to limit client access.
This question already has an answer here:
How to create auto incremented key in Firebase?
(1 answer)
Closed 2 months ago.
How can I get next key value (User03) continue from last recent key (User02) like image below:
To know the next key in this sequence, you will need to first load all the current keys.
This is one of the many reasons Firebase recommends against using arrays, since such an operation doesn't scale well, and will only work while the user is connected to the database. I recommend reading best practices for arrays in Firebase and what are Firebase push IDs.