Better understand purge

[Kartik Shah]

I need to better understand how purge works.This needs to be done on both android and ios.

We have a module that uses chat functionality ,What we need to know is how stop syncing of documents that are older than a particular time (lets say chat documents older than a month).So that we do not store large ammonuts of information on a mobile device

Purge was our initial solution ,but in case user decides to view messages older than a month or so ,we have no way to get those documents back (via somethiing called a 'load more' functionality).

Should we be using purge in this case and  then call server views runtime  to get those docs for temporary use?

[Jens Alfke]

On Oct 26, 2014, at 2:26 AM, Kartik Shah <ikar...@gmail.com> wrote:

I need to better understand how purge works.This needs to be done on both android and ios.

The docs are here.

Purge was our initial solution ,but in case user decides to view messages older than a month or so ,we have no way to get those documents back (via somethiing called a 'load more' functionality).

Sounds like you understand purge; what you're looking for is part of a TBD feature we call "subsetting", i.e. being able to easily manage a local database as a subset of a remote one.

Currently, what you can do is create a new pull replication and set its documentIDs property to an array of the IDs of the documents you want to restore.

I've been doing some prototyping of better ways to manage this. The implementation so far is in a branch of couchbase-lite-ios called feature/query. It adds a method to CBLReplication to immediately download specific documents:

/** Requests that the replicator download the documents with the given IDs from the server

    (EXPERIMENTAL).

    This can only be called on a pull replication, obviously.

    It's OK to call this while the replicator isn't running; the IDs will be remembered until

    it starts. */

- (void) pullDocumentIDs: (NSArray*)docIDs;

There's also a method to run a query against the server database, but this requires an even-more-experimental Sync Gateway branch (also called feature/query) which exposes a view-query REST API to clients.

You're welcome to try it out; it's just that it hasn't been seriously tested, it's iOS-only for now, and the API is definitely subject to change in the future.

—Jens