We have been trying to use the GetPendingDocumentIDs with little success. Sometimes the method returns nothing, sometimes it returns the documents IDs (seems to be dependent upon the status of replicator).
Ideally, we would be notified by the replicator when specific documents/revisions have been pushed successfully or whether they have failed. We can sit and poll the GetPendingDocumentIDs, but this is prone to failure and unreliability due to concurrency and timing.
I know such an event does not exist in CBL.NET 1.4.1, and I haven’t looked into CBLite 2.0 enough to know if a similar event is present.
Will there be any potential to get such a feature into CBLite 1.4? Will there be any more feature development in that branch?
Is there any other way to determine when a specific document has been pushed??
There’s not going to be any further feature development in 1.x, just high-priority bug fixes.
2.0 doesn’t have the pending-documents feature yet, but it would be good to add. Could you describe why you need to get immediate notification that a specific document has been pushed, instead of just waiting for the replication to complete (or go idle)?
Our application runs on a toughbook, and our users are prone to shutting the lid prior to all replications being completed. We can’t prevent them for doing this, so we need a better way to flag specific documents so that they can see that their changes have/have not been pushed.
The “idle” status is not always reliable, because the replications will go active -->idle --> active in rapid succession at times, which reports a false “completion” event. Also, when an error with a push for a specific document occurs, there is no structured way to correlate the error received from the sync gateway to the document that failed. The replicator sets the “LastError”, but that doesn’t tell us which specific documents were the cause.
When we are displaying multiple documents in a user’s “inbox”, we’d like to show which ones have actually been pushed, and which ones are still pending sync. If only some documents get synced before they shut the lid, it’d be nice to at least know for sure that the revision on the device actually made it to the server for back-end processing.
Thanks! That’s excellent information. I’ll record it in our issue tracker; that helps make it easier to justify (re)adding a feature and/or deciding how it should work.