Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4DA33815.5000303@mage.hu>
Date: Mon, 11 Apr 2011 19:19:17 +0200
From: Mage <mage@mage.hu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.15) Gecko/20110323 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Owen Marshall <omarshall@facilityone.com>
CC: user@couchdb.apache.org
Subject: Re: replication
References: <4DA1A9CC.4070407@mage.hu> <4DA32E5C.6090100@facilityone.com>
In-Reply-To: <4DA32E5C.6090100@facilityone.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

        Dear Owen,


On 04/11/2011 06:37 PM, Owen Marshall wrote:
>
> IIRC network errors won't kill replication -- it will merely keep trying
> until the connection is re-established and then come back into sync. But
> I could be wrong here...
I pulled out the ethernet cable from the laptop for about 5 minutes then
plugged back and continous replication didn't get restored.

However calling some cronjob once per minute seems to be acceptable.
Until a new vesion comes out with permanent replication feature.
>
> Are you *sure*? Think very carefully here.
>
> IMO, conflicts should not be seen as "bad". Instead, they should be seen
> as an intermediate state that should be resolved as soon as possible.
>
> If you design your app to watch for _conflicts: true, and handle the
> conflicts in a way that makes sense to your application, you will be
> much happier -- not only will your application "just work" without your
> pager vibrating 24x7, but you may find that your app will be able to do
> things you hadn't thought of before.
In the meantime I played a bit with CouchDB and realized that conflicts
happen when: I start working with a document on node A => I modify and
save the same document on node B => Replication happens => I try to save
the original object on node A.

So conflict can happen not during the replication but on save if I am right.

The strange thing is, at least for me, that if I modify a document on
node A *when there is no replication* for example if the link is dead
then I modify the same document on node B and after that I start
replication then the later version of the document wins and the other
version becomes "lost" without any trace. It doesn't even stays there as
previous version. At least as I experienced so far. I might missed
something.

I am not saying this is wrong I just never used a distributed database
before.

        Mage