I have documents A and B where A needs to be synced before B.
Can I use a push filter and pendingDocumentIDs to do this? My plan was to, in the push filter, check the if A is in pending docs, and block B if it is. Will this work?
My use case is that both documents were created when the app was offline and are synced at the same time.
If you do this, there is a chance that B will not sync at all. If you want to do this logic, you can set up a second one shot replicator with docIDs filtered to just A, run that to completion, and then start the normal replication.
Thanks for the reply. Can you explain why B might never sync?
Because the pull and push filters are meant for static evaluation so a failure of these is not intended to be recoverable.
There is no way to enforce ordering in replication.
If you describe the higher-level problem that is causing you to want this, maybe we can resolve that in another way.
Well, the info I gave is kind of it from my POV. A and B are ingested by a service and in order for B to be processed correctly, A needs to be processed first.
I’m a mobile dev but if this is better fixed at sync gateway I’d be happy with that. On the mobile side we have one DB with a push-pull, continuous replicator and multiple other read-only replicators for other DBs. We had a previous attempt at integrating one-shot replicators into the app but not in this particular way, so the previous suggestion may be viable.
You can put some kind of timestamp or counter into docs A and B. When you update them, update that field to a newer value in both docs.
When the service looks at the docs, if the timestamps in A and B differ, it holds off processing them.
Alternatively – I can’t remember if we expose revision IDs in the public API – you can store A’s revID as a field of B.
And the simplest approach is to merge A and B into a single document, if they’re that interdependent.