We started tryouts with the CouchBase stack and a data collection app. Right from the start, we faced issues with missing documents in CouchBase Lite after the first synchronization/replication. We ended up fixing the problem, but a couple doubts still persist.
I understand that the _all_docs call will list all documents allocated to a channel. No doubts here. For the _changes call we have to consider that we have 3 databases:
CouchBase Server
SyncGateway
CoucbBase Lite
The documentation says:
“This request retrieves a sorted list of changes made to documents in the database”
Which database are we talking about? What makes a document show in the _changes list?
Is there a way to know what changes have acctually been replicated to CouchBase Lite and what is still waiting for replication? The same question goes for CouchBase server.
Is there a way to see a list of documents which have not been replicated due to errors or conflicts?
Actually there are only two databases in question: the server and the client/app. (iSync Gateway has no storage of its own.) The _changes request to SG reports changes on the server, since the timestamp (“sequence”) given in the request. The response includes the sequence of each change, so the client can remember the last sequence it’s downloaded, and pass that value in its next changes request.
There isn’t an API to find out what’s waiting, because the client is streaming the change in fo from the server and doesn’t know all of it up front. (Otherwise if there were millions of changes, the client would have to wait a long time to read the metadata before downloading any docs, and the metadata could overflow its memory.)
Ok jens… We’re still trying to figure out how everything works. But, there is a database associated with Sync Gateway, right? At least we have to name the sync database on the API calls url. Thank you for the support.
For historical reasons, server databases are called “buckets”. Sync Gateway just adds a sync and REST API to buckets. The database name in SG is just used as the path component in the URL. It doesn’t have to match the bucket name, although that’s usually a good idea for consistency.