I’ve built a progress indicator, by creating a simple _count reduced view on Sync Gateway, and the same view on CBL. When replication is running, I’m calculating progress by comparing the two. The reason I did it this way was that the provided changesCount and completedChangesCount are not reliable for large numbers of documents (in this case in the region of 37000, plus attachments).
It all works nicely, apart from my indicator never completing for the larger replications. There always seems to be a difference of about 20, e.g. the SG view reporting 36711 and the local view reporting 36691. I’ve tried calling _resync to make sure everything is up to date, but still the same.
I don’t have the answer, but your way pick my interest, and make me ask this question, why do you need to know if the replication is completed ?
I’m trying to use couchbase since 2 months, so I’m still a beginner, I’m probably wrong, but I understand that an app using sync gateway need to be able to work with and without the connection, with and without the docs that are in the server. The goal of sync gateway is that you don’t have to care about the replication. Just make shure that it’s on when your app is online (wifi or data). Your opposite point of wiew is very interesting.
Can you explain it ?
For replication stats, I would focus on the stats provided by Couchbase Lite, and if they aren’t accurate, report an issue. However, it’s a known behavior that the total number of changes reported by Couchbase Lite may increase during the replication, which is due to the nature of the protocol and cannot be changed … is that what you mean by the Couchbase Lite stats not being reliable?
Depending on the app design, you might want to do an “initial sync” and block the user from doing anything until that initial sync has completed. Showing a percentage based progress bar is tricky due to the reason I mentioned earlier, so the best thing is to probably show a “generic spinner” that indicates progress but does not show a percentage.
You can build apps on Couchbase Lite that never sync to the cloud or each other – fully offline apps. These aren’t very common, but in that case you don’t need Sync Gateway.
Typically apps need to sync data with other instances of the app across devices, and that’s typically done via Sync Gateway running somewhere on the public internet. (peer to peer or a local Sync Gateway is also possible).
I would say the goal of Sync Gateway is to facilitate that replication, aside from peer to peer cases, which are less common.
For example, if you wanted to build an Evernote-like app, you would want to:
Sync data between devices for a single user (my notes on my iphone should appear on my ipad)
Sync data between users (you should be able to mark a note as shared with me on your android phone, and it should then appear on my iphone)
In that case Sync Data would essentially function as a “Data hub in the cloud” which all the data originating from and targeting devices would be routed through.
I mean a simple view that just counts the number of documents in a given channel or that match a given property.
the total number of changes reported by Couchbase Lite may increase during the replication
Yes that is exactly why the changes feed is not appropriate for this use case, as for larger numbers of documents it does not show when the replication has “completed” - what I need to know is when the total number of documents in CBL match those on the server, at which point the set of local data is seen as complete.
What I don’t understand is why the view on SG gives a different result to the number of documents actually replicated.
Update: at the end of a large replication, I see reported from CBL:
idle, progress = 36700 / 36700,
But from my local view I get a the number 36697. The difference seems to be different each time, and although relatively small, is a little concerning as its important that all the documents are pulled down.
I’m on couchbase-lite-ios 1.4.0 (I rely on Cocoapods), and SG 1.4.0