Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jurgvanvliet@gmail.com
 designates 209.85.219.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=cc:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=HMSJH9qZf58bP6JqvX1JpjxTNua0qqG92k7Njn3iU5VIx5EbKoRFEqw47rXHufkQp0
         fTQlFHexXVlg413VknvpEdy9itMRBrBcJh3KA7/gF21CEDwNsJfxEe7T4J+yUS00O7ev
         ZDWIbNZWrGD2p3tQNv2eTPF+96Hh8v9J6oKlE=
Cc: user@couchdb.apache.org
Message-Id: <4224356C-78BF-465D-BFC0-8F32601D3CB6@gmail.com>
From: Jurg van Vliet <jurgvanvliet@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <20090526073946.GA9022@uk.tiscali.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: struggling with couchdb in production
Date: Tue, 26 May 2009 09:52:08 +0200
References: <e282921e0905251236i6f6765e7v1e3c5cda8020e460@mail.gmail.com>
 <20090526073946.GA9022@uk.tiscali.com>


On May 26, 2009, at 9:39 AM, Brian Candler wrote:

> On Mon, May 25, 2009 at 12:36:11PM -0700, Chris Anderson wrote:
>>> a database in couchdb is the place where work comes together, in  
>>> our case
>>> this is the location where a group of people shares. combining  
>>> information
>>> from different databases will be necessary. and i really have no  
>>> clue yet
>>> how to approach this problem. so anyone?
>>
>> The easiest thing is to merge the databases with replication.
>
> In some ways this is the easiest - and in some ways it is the hardest.
>
> It will be easy if your various sources are creating distinct  
> documents. It
> will be hard if the various sources are editing the same documents -  
> because
> you will start having to deal with replication conflicts.
i think replication is not the solution for the specific problem i  
tried to sketch. i am talking about simple aggregate information (10  
most recent documents per user, for example) over potentially  
thousands of different databases. if i have to replicate all my  
databases into one big database i would start with a big one and  
replicate out to handle load. that feels like 'missing the point'.  
(though i am still struggling which point exactly :) )
>
>
> Whilst CouchDB's model for this is logically self-consistent, I  
> personally
> still believe that it's difficult to use for real-world  
> applications. For
> example, if you GET a document, you will get one arbitrary version.  
> You will
> get no indication that conflicting versions of this document may or  
> may not
> exist. If you want to ensure that your user always sees the latest,  
> resolved
> version of the document, then you need to explicitly ask for all the
> conflicting revisions, and then you need to fetch them individually  
> (AFAICS,
> even a regular "bulk fetch" using _all_docs and keys can't do this),  
> and
> then merge them in an application-specific way, and then put back  
> the merged
> version and delete all the conflicting revs.
yes and no, it all depends on how you regard your users. i think in an  
environment where many people create something together the conflicts  
have meaning. i choose to expose the conflict, meaningfully, and  
'help' the user resolve it herself.

but this is different from what we have been taught. we are all a bit  
afraid of difficult and critical users, because we might have to  
explain why things break :P i do feel it fits very well with couchdb  
though.

in an environment where the conflicts are not results of user actions  
there is no problem as well, because the conflicts are logical. (not  
necessarily the same as meaningful, though :P )

groet,
jurg.
>
>
> Regards,
>
> Brian.