How do I tell Sync GW to pull only the last revision of a document?

Synchronizing our app for first time from cloud it’s delaying too long. The number of documents is less than 2,000 but I see that for each document, there’s a number of revisions that are being downloaded to the mobile app. Replication log tells that the total number of documents is grater than 12,000.
I have checked if there are conflicts and looks like there aren’t.
How do I tell sync gw to pull only the last revision of the documents? If this is possible, is it a good practice or shall this approach give any problem?
BR Sandra

The replicator only sends/receives the current revision.

However, if you’ve got unresolved conflicts, a document can have multiple current revisions. That sounds like what’s happening to you. You should add code to your app to resolve conflicts as they happen, so that they don’t pile up.

Ok thanks, working on that.
Two more questions:

  1. once I resolve a conflict in one of my mobile devices, will that fix be replicated to all the rest of mobile devices and cloud server?
  2. When I purge a document in a mobile device, all revisions are purged?

BR, Sandra

  1. Yes, the revisions that resolve conflicts are replicated like any other revision.
  2. IIRC the REST API allows you to purge individual revisions, but the native API just purges the entire document.

Thanks a lot Jens!
BR, Sandra

Hi Jens, I opened CBL database in database browser tool and saw that there are a lot of not current revisions that are stored in db:00
Here are more that 100 thous. records! As you can see here are no documents that are conflicted (because of different doc id-s). All of them are downloaded by replicator and written info DB - it wastes a lot of time in my app.

Could you please say what is the way to not download and save this useless(as I think) data?

The database doesn’t store the old revisions, but it does store their metadata (revision ID plus a few flags.) This is needed by the replicator to detect and manage conflicts.

It only takes up a few tens of bytes per revision, and it stores only the 20 latest revisions of any document. If you want to store less than that, set the maxRevTreeDepth property of the database to a number less than 20. (But the lower it goes, the more likely you are to get false conflicts if the local and server databases have diverged.)