incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jurg van Vliet <jurgvanvl...@gmail.com>
Subject Re: struggling with couchdb in production
Date Tue, 26 May 2009 08:15:38 GMT

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.


Mime
View raw message