couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <>
Subject Re: Help needed: is couchDB a good fit for my app?
Date Thu, 21 Apr 2011 19:09:29 GMT
Not saying that a database per user isn't a good idea (probably would work
pretty well with the future replication database feature), but some
alternatives that I could think of are:

You could potentially have something in front of couchdb to restrict the
access to regular doc GET/POST/PUT and force the outside world to pull using
show and list functions. I believe you could user the user's context/session
object that is in the request object (pretty sure show/list get it) to
filter out the non-user/public data. You'll probably have to always use
update functions as well to avoid overriding tags.

That or perhaps have the generic document stand alone and then the user
specific stuff in a separate document owned by the user. I believe still in
this scenario you would have to put something in front of couchdb to
restrict access if they are private. You would be able to make use of
filters for replication and changes pretty effectively I think.

On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage <> wrote:

> >> You might want some architecture like this:
> >>
> >>                   [] Public Docs db           |
> >>                                                       |  <----- hosted
> >> [] User 1db    [] User 2 db  []....         |
> >> ------------------------------------------------------
> >>
> >> [] User1 phone db   [] User 2 Phonedb   []....
> >>
> >> Then have replication between phone and user db. Then have replication
> >> from Userdb to public docs db with a filter to take out private
> >> tags...
> >>
> > Hum, something like that could yes. But I have a question regarding the
> > stats. First, a tag can only take a value in a predefined set of value
> > for that tag. So, is it possible that instead of filtering the tag
> > completely, I update the stat of the value accordingly (+1 if the value
> > has been chosen by the user, -1 if the user changed to another value or
> > reset the tag)?
> CouchDB filtering is currently a yes/no operation per doc. So you
> would want to have related docs to the tag that hold the 'stat of the
> value'. Filter the parent tag doc, and let the 'stat of the value'
> docs go back to the public db.
> >
> > Oh, and also, I read that there is a limit depending on the OS for the
> > number of concurrent databases. Won't that be a problem if there is a
> > lot of users (which will hopefully be the case;)?
> Yes, there will be a limit on how many for concurrent dbs per OS. It
> is really high anyway. Someone else will have to give real life
> numbers on this. But if you hit the wall, just add more servers. They
> are cheap as chips :) The couch replication model is nice because it
> is flexible with how you might grow.
> Ryan

“The limits of language are the limits of one's world. “ -Ludwig von

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message