Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <15983520.129271280793139373.JavaMail.jira@thor>
Date: Mon, 2 Aug 2010 19:52:19 -0400 (EDT)
From: "Randall Leeds (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-141) Replication should respect since=N
 seq-num parameter
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Randall Leeds commented on COUCHDB-141:
---------------------------------------

As far as implementation goes, two things I think should be considered:

1) I think a user of this feature would expect that firing off a future replication would pick up where this one left off. In that case, this new parameter should *not* be included in the calculation of the replication id. It should checkpoint as a replication from seq zero.

2) If this parameter is specified, any existing log file should be *ignored*. That way, someone could later go back and say, "Oh, whoops, I actually need to start earlier." An old log, if it exists, does need to be loaded (but not searched) so that it can be updated with an appropriate _rev and not get a conflict. I don't think the log should be truncated in case we want to expose or inspect the historical data later.

> Replication should respect since=N seq-num parameter
> ----------------------------------------------------
>
>                 Key: COUCHDB-141
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-141
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 1.0
>            Reporter: Jan Lehnardt
>            Priority: Minor
>
> The changes feed has a since=Seq param which can be used to start listening somewhere other than the beginning of the database history. The replicator should respect this option as well.
> This can also be used by administrators who are bringing a CouchDB instance up from a file that was physically copied between servers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.