My push replication replicates some of the local docs. I query the local DB for a list of doc IDs to be pushed and then I set ReplicatorConfiguration.DocumentIDs accordingly.
This works great for doc creation, and update, but I cannot find a way to push a doc deletion.
My query won’t return the deleted doc’s ID and therefore I can’t push them.
Answering my own question maybe, but I’m still interested in your thoughts about filtered replication.
Instead of letting my app decide which local docs to push, the app could push all of them (leaving ReplicatorConfiguration.DocumentIDs = null).
Instead I would make the Sync Function responsible for deciding which to accept, and which to reject.
How about scalability in this alternative design ? Would the push replication resend all previously rejected docs on every subsequent push ?
The pusher should be smart enough to understand that a revision was rejected and just write a warning into the logs about it and move on but I’m not 100% sure. A quick glance at the relevant section of LiteCore backs this up though.
Does the sequence number tracking make sure that a rejected rev won’t be retransmitted in the next push replications over and over ? (That’s what I meant by scalability above)
Cool, I just confirmed it and wrote a test case for it.
Thanks for the quick response @borrrden.
Now back to the original issue:
I don’t see a way to use filtered push replication (with ReplicatorConfiguration.DocumentIDs) to push a document deletion. Or am I overlooking something here ?
You probably aren’t missing anything. It’s not a scenario that I’m familiar with off the top of my head, and I would assume that it should work and that not working is a bug.
The result is that the document deletion is not pushed despite the replication succeeding?
If I knew the docId that was deleted, it might work. But that’s not feasible in my design. The document is already deleted, and I can’t figure out how to query for deleted docIds. Or is there a way to query it?
There is not currently a way to query for deleted documents. The thinking in 2.0 is that we are trying to provide the current state of the database, and deleted documents are supposed to be “gone” so they won’t show up in queries. If this functionality is a must for you, then petitioning Couchbase to add it would be your best bet (although it’s going to be a weird feature to add since we are trying to align with N1QL, which doesn’t offer the ability to query “deleted” documents). Maybe what you are really after are push filters and/or validation functions, which is a feature that is currently in LiteCore but not exposed in Couchbase Lite.
Thank you @borrrden for your assistance. For now I do not need the ability to query locally for deleted revs. I believe I can do without filtered push replication. Filtering in the sync function looks like the better solution anyways.
Couchbase Lite Core supports querying for deleted documents. IIRC, in the API design process it was decided not to expose it as a public API. I think it should be exposed (for purposes like this.)
I am curious how the push filters would work in 2.x. In CB Lite 1.4 I was able to define a view for the filtered push replication. In 2.x what would define the filter ?
CBL 1.4 push filters aren’t based on views. The filter is a function (block, lambda) that takes the document body as a parameter and returns true/false.