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