[
https://issues.apache.org/jira/browse/COUCHDB-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246102#comment-15246102
]
ASF subversion and git services commented on COUCHDB-2988:
----------------------------------------------------------
Commit 986549984be44c7e5cd66f3773d2bdd94f506e5c in couchdb-couch-replicator's
branch refs/heads/master from [~kzx]
[
https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-replicator.git;h=9865499
]
Implement Mango selectors for replication
Replication document should have a "selector"
field with a Mango selector JSON object
as the value.
For example:
```
{
"_id": "r",
"continuous": true,
"selector": {
"_id": {
"$gte": "d2"
}
},
"source": "http://adm:pass@localhost:15984/a";,
"target": "http://adm:pass@localhost:15984/b";
}
```
This feature underneath uses the _changes feed
Mango selectors capability.
Replicator docs js validation function has been
updated to return an error if it notices user has
specified both `doc_ids` and `selector`. Or
they specified `filter` and either of the other
two.
Replication options parsing also checks for those
mutually exclusive fields, as replications can be
started from the `_replicate` endpoint not just
via the docs in `*_replicator` dbs.
When generating a replication id, Mango selector
object is normalized and sorted (JSON fields
are sorted inside objects only). That is done in order
to reduce the chance of creating two different
replication checkpoints for same Mango selector.
Jira: COUCHDB-2988
> Allow query selector as changes and replication filter
> ------------------------------------------------------
>
> Key: COUCHDB-2988
> URL: https://issues.apache.org/jira/browse/COUCHDB-2988
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core, Mango
> Reporter: Nick Vatamaniuc
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
