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=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Sf4QrFLCslfugh/cMwrz1JwST6Uq4NpNV+Ff6Hk9H+O/aYMfnVUomxJ9KWG4giM0cB
         4r8EKMKiTRhTRpQOzI8+W0jyfxSPbQaK0KKQeoguPp1oUTJ8o38Pq4Gd0qiAnA+nJ8Ve
         OGfVVjNs2AxEvg/AO3ST5ZGutDiVl6sHMS1+o=
Message-Id: <F36D1230-AAEC-4762-AD0C-4E3C9BC9065D@gmail.com>
From: Jurg van Vliet <jurgvanvliet@gmail.com>
To: user@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 v935.3)
Subject: Re: struggling with couchdb in production
Date: Tue, 26 May 2009 10:15:38 +0200
References: <4224356C-78BF-465D-BFC0-8F32601D3CB6@gmail.com>
 <20090526080535.GB9381@uk.tiscali.com>


On May 26, 2009, at 10:05 AM, 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.
i tend to think that databases in couchdb should be self-contained  
enough to have meaning in the application. if i take my project on my  
travels i don't need all the information of all users in the system,  
just the names of my team member is enough.

i would like to use a database as a vehicel for replication, or for  
migration. (i hope what i am saying is somewhat understandable.)
>
>
> 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".

true. in fact i can imagine that is very useful information. (i don't  
have that problem yet but i am sure i will :P )

>
>
> Regards,
>
> Brian.