Greetings everybody,
We are looking for a way to figure out the number of changes that our server contains that the local database does not. We are able to get the most current sequence number from the server, but is there a way to do the same for the local database? We’re using CBL 1.2.
It’s Database.lastSequence, but that’s not going to help you because there’s no correlation between server and client sequence numbers, and because the client doesn’t necessarily have access to all the docs on the server.
The only way to do this is to do what the replicator does: remember the latest server sequence that the local DB is up to date with, then request the server’s _changes feed passing that last sequence as the since parameter, then count the number of items returned in the feed.
Sorry, there’s no API for that currently.
What’s the reason you need to implement this?
Our app requires that our users have most, if not all, of the data available for their channel(s) before they can begin working.
So far, we have accomplished that by comparing the number of docs the local DB has compared to what we should have. The issue with this approach is that all of the documents could have had changes made to them. If the local DB already has those docs, the load screen would not detect those changes and the user would be allowed in prematurely.
What we’re looking for is a way to look at the number of changes that need to be pulled. If we were using one-shot replication it would be simple enough to grab the latest server sequence each time that replication ended. However, we are using continuous replication and it seems like it would be bit more complicated to know exactly when to grab the latest server revision to store.
If we had some way to grab that directly from the replicator, it would be a much more simple task and I believe that it would prove useful for many developers.
Is there a specific reason as to why it is not exposed, or is it just something that hasn’t been requested until now?
The replicator could tell pretty efficiently whether there are any docs to pull, but determining how many would take significantly longer (proportionally to the number of changes), since it has to download and parse the entire changes feed. Generating the feed is also fairly expensive for the server.
It would be easiest to just run a pull replicator and see whether it reports docs that need to be synced (its total-docs property goes > 0) before the replicator finishes or goes idle.
OK I see what you’re saying.
What we may try is initially running one-shot push and pull replicators. Once those replicators are finished, we will allow them past the loading screen and then fire up the continuous replicators for further use of the app.
If I’m thinking about it correctly, this should provide a solution for our situation.
Do you have any thoughts about this solution? Any potential problems that stand out in your mind?