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
--