When the device is offline, the app stores any Firestore changes locally and update them when the internet connection is back. Is there a way to check in the app if the local changes finished uploading Firestore?
There's no API to get a list of the pending writes, nor is there a flag that signals whether there are pending writes. But there are a few things you can do:
For a specific write, you can attach a completion listener to detect when it has completed. When the Future that the write resolves, the write has been committed on the server.
When you're getting a DocumentSnapshot, you can check the hasPendingWrites property in its metadata to see whether the snapshot has pending changes.
Related
I am wondering if IndexedDB is the only cache Firestore uses.
To be clear, I am not talking about persisting data with enableIndexedDbPersistence(). I am talking about an internal store for the sole purpose of optimistic updates when the app is still in state. Is there something similar to redux, svelte store, or InMemoryCache which is run in the background when a subscription is open?
It seems that when I use onSnapShot() for a list of items, and I update an item in the list with setDoc elsewhere, the UI gets updated immediately, optimistically.
Perhaps Firestore is just that quick where the data is sent to the server, changed, and sent back to the client with the UI being updated that quickly, but it seems to me it is an optimistic update.
Does Firestore use any other caching techniques or state management techniques when the app is still running besides IndexedDB?
J
References (maybe releated):
Does Firebase cache the data?
As long as you have an active onSnapShot listener, the Firestore SDK will have a copy of the latest query snapshot for that listener in memory. If you attach another listener to the same (or partially overlapping) data, that listener may get (part of) its data from the existing listener.
So when you perform an update in the same client as where you have a listener, the SDK immediately applies that update to its local copy of the data and fires an event (so that is almost instantly). It then sends the update to the server, which executes it on the backend storage layer. If that update gets rejected (a relatively rare occurrence), the client will revert the change it make locally and fire another event with the corrected state.
An easy way to see this in practice is to perform a write operation that is rejected by your security rules. You'll briefly see the invalid state on the client, before it reverts to the correct state. This invalid state only happens on the client that performs the invalid write, so it's typically fine to ignore it there.
If I perform an update operation on a document in Firestore, and I know for certain that the document exists, what possible reason, outside of my control, could an error be generated?
And if an error is generated, is the update automatically retried?
Or is this update only automatically retried if there is no connection and Firestore's offline capabilities take over?
If I perform an update-data operation on a document in Firestore, and I know for certain that the document exists, what possible reason, outside of my control, could an error be generated?
A common error that can arise, is when the Firebase servers reject an operation due to improper security rules. Meaning that you are not allowed to do that particular operation.
And if an error is generated, is the update automatically retried?
No, that will not happen while online.
Or is this update only automatically retried if there is no connection and Firestore's offline capabilities take over?
Yes, that will indeed happen. All operations that take place while offline, are added to a queue. Behind the scenes, Firestore SDK tries to reconnect until the devices regain connectivity. Once the user regains the connection, every change that is made while offline will be updated on Firebase servers. In other words, all update operations will be committed on the server, as long as you have proper rules.
https://firebase.google.com/docs/firestore says:
Like Realtime Database, Cloud Firestore uses data synchronization to update data on any connected device.
I'm trying to figure out what this "data synchronization" consists of.
https://firebase.google.com/docs/firestore/manage-data/enable-offline says:
When persistence is enabled, Cloud Firestore caches every document received from the backend for offline access.
Does Cloud Firestore update that cache whenever changes happen in the back end?
For example, if I have a certain document in my cache, does the document
update (a) automatically when that document is changed in the back end or
(b) whenever I do a query that uses that document, and I happen to be online
at the time?
UPDATE
I'm going to restate my last paragraph, because it's been misunderstood by
at least one person.
Imagine the following scenario:
I have a smartphone. To make things easy, assume the smartphone
is online all the time.
Installed on this smartphone is a mobile app that contains the Firestore SDK.
The app has enabled the Firestore cache.
The cache contains, say, 1000 documents.
Now my question is: if one of these documents changes in the cloud (not on
the smartphone), under what circumstances will the Firestore SDK update the
document in the cache? Will it (a) update the document automatically, soon
after the change on the cloud, or (b) update the document the next time the
mobile app does a query that uses the document?
Both of the highlighted paragraphs are in my opinion straightforward explanations, and to answer your questions:
Does Firestore update that cache whenever changes happen in the back end?
Yes, if you are offline and some documents are changed, once you are back online, you get all changed documents and vice versa, if you change some documents locally (in your cache), when you're back online, all changed documents are sent to the Firebase servers.
If you have a query that returns 10 documents, it means that you are in sync with 10 documents, which basically means that if of those 10 documents is changed, your listener is triggered only for that change.
does the document update (a) automatically when that document is changed in the back end
Yes, first of all in your cache and once you are back online, also on Firebase servers.
whenever I do a query that uses that document, and I happen to be online at the time?
Whenever you are online and a document is changed, you are notified in realtime.
Edit:
if one of these documents changes in the cloud (not on the smartphone), under what circumstances will the Firestore SDK update the document in the cache? Will it (a) update the document automatically, soon after the change on the cloud, or (b) update the document the next time the mobile app does a query that uses the document?
As long as you are in sync with those documents, it happens in the second moment the document is changed. What I mean through in sync is, that you are using in your code a get() call to get those documents or if you are listening in realtime for documents changes. Simply creating a reference to a document or a query without using a listener, you aren't notified in any way.
update the document the next time the mobile app does a query that uses the document?
Is not correct since you are online and in sync with the documents, the listener is triggered instantly.
Edit2:
In short, a listener is called everytime a change in a document occurs. "Next time the app does the query" is not correct sentence because when you create a query and attach a listener, you are always in sync with the database and when a document is changed you are immediately notified. It is not like, the documents are chainging in the database and when I query (at some point of time), I get the changes, no, you are always notified as the changes occur. That's the beauty of a realtime database, to be notified as the changes are happening :)
If you have the local cache enabled, Firestore automatically stores any documents it receives in that local cache.
This only happens when your app is requesting the documents by calling get() or onSnapshot. Firestore does not automatically request the documents on your behalf. So if your app doesn't request the document, the cache will not be updates.
I'm using react-native-firebase's firestore library, specifically offline persistence for an app that needs to record transactions offline at events, it works very well, when the device goes online it syncs pending transactions.
However I haven't found a way to know which transactions are pending to be sync'ed or at least that transactions are indeed pending. I'd like to display this information so when the event closes the manager could connect the devices to a portable wifi, and know that all transactions where correctly uploaded to the server.
Have a cloud function that listens for all new documents in a collection and then updates them with a Boolean true "synchronised" field. Listen with the client for an update to the synchronised field. Tally up all those without/with a false synchronised field to find out how many are yet to sync/use this data in whatever way you need to.
In my Android app I am writing data to firestore which is being validated with the help of security rules. Since writes work offline too, my (invalid) write task will return success if device is offline. But when the device comes online, the security rule will block the write and the data will disappear from the client. Is there a way for me to know that the write failed? Is it possible for a cloud function to be triggered if security rule fails so that I can inform the user that their write failed after going back online?
When you say "my (invalid) write task will return success if device is offline", this is not exactly how it works. When you write a document to Firestore the SDK will only confirm the write if the app is online and the server confirms that it's written. When you perform a write, the API is going to give you some sort of handle into that operation (Android Task, JavaScript promise) will be completed or resolved when that write actually finishes.
If you are offline, you'll never know for sure if the write was going to work, but the written document will still show up in queries. If you want to know if that document finally finished its write, you'll have to request metadata for that document, and check if that document has an outstanding pending write. For example, on Android, use hasPendingWrites() to find out if the document you have in hand was written.
The SDK doesn't provide you with a way of knowing when your documents sync after it's cold booted. But you can take matters into your own hands by remembering all the paths of the documents that are important to track, persist them locally, then load those paths on cold boot to check for success. You'd add listeners to those documents and check:
If the document doesn't exist, that means the write was rejected before you attached the listener.
If the document exists and hasPendingWrites(), that means the sync is still waiting to happen.
If the document exists without pending writes, it got synchronized successfully.
This strategy only works for adding new documents. For updating documents it's more difficult because a document without pending write may just be an old version of the document before the update sync failed. So you'd need to put some other field in the update that indicates if the update succeeded.