[ 
https://issues.apache.org/jira/browse/COUCHDB-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495629#comment-16495629
 ] 

ASF subversion and git services commented on COUCHDB-3326:
----------------------------------------------------------

Commit b69a030a385e36e4da6d04eb6b0ad343fa997dc5 in couchdb's branch 
refs/heads/COUCHDB-3326-clustered-purge-pr5-implementation from 
[~paul.joseph.davis]
[ https://gitbox.apache.org/repos/asf?p=couchdb.git;h=b69a030 ]

[02/N] Clustered Purge: Update single node APIs

This patch updates the single node API implementations for use with the
new clustered purge API. At the single node level the major change is to
store a history of purge requests that can then be consumed by various
other parts of the database system.

The simpler of the major areas to use this new functionality will be any
secondary indices. Rather than checking that only a single purge request
has occurred each secondary index will store a _local document
referencing its oldest processed purge request. During index updates
each secondary index implementation will process any new purge requests
and update its local doc checkpoint. In this way secondary indexes will
no longer be sensitive to reset when multiple purge requests are issued
against the database.

The two other major areas that will make use of the newly stored purge
request history are both of the anit-entropy mechanisms: read-repair and
internal replication.

Read-repair will use the purge request history to know when a node
should discard updates that have come from a node that has not yet
processed a purge request during internal replication. Otherwise
read-repair would effectively undo any purge replication that happened
"recently".

Internal replication will use the purge request history to be able to
mend any differences between shards. For instance, if a shard is down
when a purge request is issue against a cluster this process will pull
the purge request and apply it during internal replication. And
similarly any local purge requests will be applied on the target before
normal internal replication.

COUCHDB-3326

Co-authored-by: Mayya Sharipova <may...@ca.ibm.com>
Co-authored-by: jiangphcn <jian...@cn.ibm.com>


> Implement clustered purge API: _purge
> -------------------------------------
>
>                 Key: COUCHDB-3326
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-3326
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: Database Core, Documentation, HTTP Interface
>            Reporter: Mayya Sharipova
>            Priority: Major
>
> This implements the clustered purge API:
> {code:}
> curl -H 'Content-Type: application/json' -X POST 
> "http://adm:pass@127.0.0.1:5984/test1/_purge"; -d 
> '{"d1":["3-410e46c04b51b4c3304ed232790a49da", 
> "3-420e46c04b51b4c3304ed232790a35db"],"d2":["2-a39d6d63f29a956ae39930f84dd71ec3"],
>  "d3":["1-bdca7a3ac9503bf6e46d7d7a782e8f03"]}'
> {code}
> Response: status_code 201 or 202
> {code:javascript}
> {
>   "purged": [
>     {
>       "ok": true,             //Quorum was reached, at least W nodes 
> successfully purged doc
>       "id": "d1",
>       "revs": [
>         "3-410e46c04b51b4c3304ed232790a49da",
>        "3-420e46c04b51b4c3304ed232790a35db"
>       ]
>     },
>     {
>       "accepted": true,      //Quorum was NOT reached, but request was 
> accepted
>       "id": "d2",   
>       "revs": [
>         "2-a39d6d63f29a956ae39930f84dd71ec3"
>       ]
>     },
>     {
>       "ok": true,   
>       "id": "d3",
>       "revs": []            //(DocId or Revs missing) OR (Revs are not leaf 
> revisions) 
>     }  ],
>   "purge_seq": 
> "6-g1AAAABMeJzLYWBgYMpgTmHgz8tPSTV2MDQy1zMAQsMckEQiQ5L8____sxKZ4UoMcSrJAgC9PRRl"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to