Hi,
We are trying to use Couchbase lite 2.0 with Sync gateway 2.0 community edition for one of our application.
We want to know the list of documents which are yet to be synchronized. Is there any possibility to get the same something similar like pendingDocumentIDs of Replication Class in the previous versions in 2.0
You are right. We don’t support pendingDocumentIDs in 2.0. It’s a feature that we are tracking for future releases. One option right now is to to use the Replicator progress indicator to see if documents are all synced up . Again, does not give you the level of granularity that you are looking for but you know if there are any pending documents that have not been synced.
Another option is to wait till replicator status goes idle…
FYI, CBL 2 won’t work with SG 1.5 — CBL 2 only supports the new (WebSocket) replication protocol, while SG 1.5 only supports the old (REST) one. You’ll need SG 2.0.
We don’t have an exact date but it will very likely be in the release that follows 2.1 (2.1 is scheduled to be out end of August) . In meantime, please use the options suggested in the earlier post.
Thanks for the update. along with this we also getting a way to know what are the documents are going to be part of relpication? Earlier 1.x we used to get this info by applying filters.
That’s not in 2.0 and is for consideration in the release post 2.1. If you are using one-shot replication you can use documentIds for push filtering . (Also for future, better to open a new thread for new questions)
We are in the process of adding a feature that is not quite the same but I believe you can use for the same result. It is called replication eventing and allows you to get a callback when a document is pushed or pulled. If you know which documents are important for you, you can monitor the event for a callback for that document. Otherwise we have not scheduled the pending document ID feature yet.
Hmm - i would probably need to keep track which documents should be pushed and which are already pushed. (is push order deterministic?)
In fact the only real thing is to know if everything in the database got pushed to server, but relying on the replicator isn’t really working while app start offline and stays offline. At least this was the case in 1.4. or am i wrong with this observation?