Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of super.ronny@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=NZ+Od9SagXFiCCUmg8bIdLeUt9z+XxME+O0A08OPYhmwWuLhtDFcKAQYG5eMQPfUe0
         YMvlHZ9IUwlKxcGP1GPeJteyGQK7IlnK9mINcwrqmQralxaI3yclbAGDnQ/Zf3vD6zSN
         KMTE8RRUYwSuDIRZRk5I/JM2KknUH53jfHBLs=
Message-ID: <5871b9da0809180630m4f880416n8d0eaa0f27ff7c6c@mail.gmail.com>
Date: Thu, 18 Sep 2008 15:30:51 +0200
From: "Ronny Hanssen" <super.ronny@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: Bulk Load
In-Reply-To: <8A3EC58E-8790-4837-A881-37FE1275BCDA@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_21059_33548945.1221744651990"
References: <48CBEAC7.1030403@yahoo.com>
	 <5871b9da0809140245j6a3933b8r6755f801e592b05d@mail.gmail.com>
	 <076CE1E1-568E-4891-92BF-84E79082A7AB@apache.org>
	 <5871b9da0809141449o396a14fehac44316cdeac435c@mail.gmail.com>
	 <E26B42AC-7AE4-4983-962B-473CBA6FF6C7@apache.org>
	 <e2111bbb0809170834r2a87533fw4b5ef7bc4289a7ad@mail.gmail.com>
	 <e282921e0809170839m5b462c8ck248acee9c4f67215@mail.gmail.com>
	 <e2111bbb0809170913uadc2616p75c0ae5a81517999@mail.gmail.com>
	 <5871b9da0809171835v1ed56f4bv5761eaaf901d394d@mail.gmail.com>
	 <8A3EC58E-8790-4837-A881-37FE1275BCDA@apache.org>

------=_Part_21059_33548945.1221744651990
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think I got it, kinda :). At least for a single node setup. How to solve
this in a multi node setup is beyond me, but I guess that some patterns will
emerge as people start using CouchDB. As for now CouchDB is still only
running on a single node anyway. The calls to CouchDB are not distributed
that is. I know replication work, but only as a manual feature, right?
Thanks,
Ronny

2008/9/18 Jan Lehnardt <jan@apache.org>

> HI Ronny,
>
> not sure what you are trying to achieve here?
>
> My solution is good for a single node instance, which is, if I
> remember correctly what you asked for. It ignores the multi-node
> setup and merging revisions over multiple nodes. Which is exactly
> what CouchDB does for the simple reason that it is not easy to do :)
>
> Since you are manually handing the list of past revisions, you'd need
> to do the history merge on a multi-node conflict on your own.
>
> Cheers
> Jan
> --
>
>
> On Sep 18, 2008, at 03:35, Ronny Hanssen wrote:
>
>  Hm.
>>
>> In Paul's case I am not 100% sure what is going on. Here's a use case for
>> two concurrent edits:
>>  * First two users get the original.
>>  * Both makes a copy which they save.
>> This means that there are two fresh docs in CouchDB (even on a single
>> node).
>>  * Save the original using a new doc._id (which the copy is to persist in
>> copy.previous_version).
>> This means that the two new docs know where to find their  previous
>> versions. The problem I have with this scheme is that every change of a
>> document means that it needs to store not only the new version, but also
>> it's old version (in addition to the original). The fact that two racing
>> updates will generate 4(!) new docs in addition to the original document
>> is
>> worrying. I guess Paul also want the original to be marked as deleted in
>> the
>> _bulk_docs? But, in any case the previous version are now new two new
>> docs,
>> but they look exactly the same, except for the doc._id, naturally...
>>
>> Wouldn't this be enough Paul?
>> 1. old = get_doc()
>> 2. update = clone(old);
>> 3. update.previous_version = old._id;
>> 4. post via _bulk_docs
>>
>> This way there won't be multiple old docs around.
>>
>> Jan's way ensures that for a view there is always only one current version
>> of a doc, since it is using the built-in rev-control. Competing updates on
>> the same node may fail which is then what CouchDB is designed to handle.
>> If
>> on different nodes, then the rev-control history might come "out of synch"
>> via concurrent updates. How does CouchDB handle this? Which update wins?
>> On
>> a single node this is intercepted when saving the doc. For multiple nodes
>> they might both get a response saying "save complete". So, these then
>> needs
>> merging. How is that done? Jan further on secures the previous version by
>> storing the previous version as a new doc, allowing them to be persisted
>> beyond compaction. I guess Jan's sample would benefit nicely from
>> _bulk_docs
>> too. I like this method due to the fact that it allows only one current
>> doc.
>> But, I worry about how revision control handles conflicts, Jan?
>>
>> Paul and my updated suggestion always posts new versions, not using the
>> revision system at all. The downside is that there may be multiple current
>> versions around... And this is a bit tricky I believe... Anyone?
>>
>> Paul's suggestion also keeps multiple copies of the previous version. I am
>> not sure why, Paul?
>>
>>
>> Regards,
>> Ronny
>>
>> 2008/9/17 Paul Davis <paul.joseph.davis@gmail.com>
>>
>>  Good point chris.
>>>
>>> On Wed, Sep 17, 2008 at 11:39 AM, Chris Anderson <jchris@apache.org>
>>> wrote:
>>>
>>>> On Wed, Sep 17, 2008 at 11:34 AM, Paul Davis
>>>> <paul.joseph.davis@gmail.com> wrote:
>>>>
>>>>> Alternatively something like the following might work:
>>>>>
>>>>> Keep an eye on the specifics of _bulk_docs though. There have been
>>>>> requests to make it non-atomic, but I think in the face of something
>>>>> like this we might make non-atomic _bulk_docs a non-default or some
>>>>> such.
>>>>>
>>>>
>>>> I think the need for non-transaction bulk-docs will be obviated when
>>>> we have the failure response say which docs caused failure, that way
>>>> one can retry once to save all the non-conflicting docs, and then loop
>>>> back through to handle the conflicts.
>>>>
>>>> upshot: I bet you can count on bulk docs being transactional.
>>>>
>>>>
>>>> --
>>>> Chris Anderson
>>>> http://jchris.mfdz.com
>>>>
>>>>
>>>
>

------=_Part_21059_33548945.1221744651990--