Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <2BB51A49-3A43-4404-B0A4-8EE7756AD458@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <20090526080535.GB9381@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 v930.3)
Subject: Re: struggling with couchdb in production
Date: Wed, 27 May 2009 19:41:54 +0200
References: <4224356C-78BF-465D-BFC0-8F32601D3CB6@gmail.com>
 <20090526080535.GB9381@uk.tiscali.com>


On 26 May 2009, at 10:05, Brian Candler wrote:

> On Tue, May 26, 2009 at 09:52:08AM +0200, Jurg van Vliet wrote:
>> 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 :) )
>
> Possibly, having thousands of different databases isn't the right  
> map to
> your problem domain, since you can't have a view spanning multiple
> databases.
>
> Multiple databases make sense where the data is entirely self- 
> contained
> (data belonging to one user), especially for virtual hosting where  
> it's a
> benefit that data cannot leak from one database to another.
>
> In an application I'm working on at the moment, I have one database  
> per user
> - but a separate global login database holding the usernames and  
> passwords
> and pointers to each user's database, so at login time I only need  
> to query
> one view.
>
>> 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.
>
> Yes of course; I don't mean that automated conflict resolution is  
> required.
> What I mean is - CouchDB *hides* the conflicts, whereas you and I  
> want them
> *exposed*. It is not easy even to say "give me all conflicting  
> versions of
> this document".

`GET /db/doc?conflicts=true` gives you a new `_conflicts` member with an
array value of all conflicting revisions (that you then have to fetch  
separately).
Do you mean that something like `include_docs` would be handy here?

Cheers
Jan
--