couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clément Vollet <cvol...@gmail.com>
Subject Re: Help needed: is couchDB a good fit for my app?
Date Thu, 21 Apr 2011 22:19:12 GMT
Le 21/04/2011 12:09, Sean Copenhaver a écrit :
> 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.
>
Hum, that may be another option yes. Thanks, that provides me with
another argument to convince my boss to use CouchDB (which seems, quite
frankly, awesome).
> On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage <ryan.ramage@gmail.com> 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
>>
>
>


Mime
View raw message