Interface ReplicationDocument

Schema for a map of attachment name to attachment metadata.

Schema for a list of document revision identifiers.

Deletion flag. Available if document was removed.

Schema for a list of document revision identifiers.

Document ID.

Document's update sequence in current database. Available if requested with local_seq=true query parameter.

Schema for a document revision identifier.

Schema for list of revision information.

Schema for a list of objects with information about local revisions and their status.

Cancels the replication.

Defines replication checkpoint interval in milliseconds.

HTTP connection timeout per replication. Even for very fast/reliable networks it might need to be increased if a remote database is too busy.

Configure the replication to be continuous.

Creates the target database. Requires administrator privileges on target server.

Request parameters to use during target database creation.

Schema for a list of document IDs.

The name of a filter function which is defined in a design document in the source database in {ddoc_id}/{filter} format. It determines which documents get replicated. Using the selector option provides performance benefits when compared with using the filter option. Use the selector option when possible.

Maximum number of HTTP connections per replication.

Schema for a map of string key value pairs, such as query parameters.

Number of times a replication request is retried. The requests are retried with a doubling exponential backoff starting at 0.25 seconds, with a cap at 5 minutes.

JSON object describing criteria used to select documents. The selector specifies fields in the document, and provides an expression to evaluate with the field content or other data.

The selector object must:

• Be structured as valid JSON.
• Contain a valid query expression.

Using a selector is significantly more efficient than using a JavaScript filter function, and is the recommended option if filtering on document attributes only.

Elementary selector syntax requires you to specify one or more fields, and the corresponding values required for those fields. You can create more complex selector expressions by combining operators.

Operators are identified by the use of a dollar sign $ prefix in the name field.

There are two core types of operators in the selector syntax:

• Combination operators: applied at the topmost level of selection. They are used to combine selectors. In addition to the common boolean operators ($and, $or, $not, $nor) there are three combination operators: $all, $elemMatch, and $allMatch. A combination operator takes a single argument. The argument is either another selector, or an array of selectors.
• Condition operators: are specific to a field, and are used to evaluate the value stored in that field. For instance, the basic $eq operator matches when the specified field contains a value that is equal to the supplied argument.
• Only equality operators such as $eq, $gt, $gte, $lt, and $lte (but not $ne) can be used as the basis of a query. You should include at least one of these in a selector.

For further reference see selector syntax.

Start the replication at a specific sequence value.

Replication socket options.

Schema for a replication source or target database.

Address of a (http or socks5 protocol) proxy server through which replication with the source database should occur.

Schema for a replication source or target database.

Address of a (http or socks5 protocol) proxy server through which replication with the target database should occur.

Specify if checkpoints should be saved during replication. Using checkpoints means a replication can be efficiently resumed.

Schema for the user context of a session.

Replicate only the winning revisions. Replication with this mode discards conflicting revisions. Replication IDs and checkpoints generated by this mode are different to those generated by default, so it is possible to first replicate the winning revisions then later backfill remaining revisions with a regular replication job.

Controls how many documents are processed. After each batch a checkpoint is written so this controls how frequently checkpointing occurs.

Controls how many separate processes will read from the changes manager and write to the target. A higher number can improve throughput.