BTW what is the preferred way to answer? Top-posting or inline? Yeah the scalability is one of our main concerns and we could put the logic in the middleware but I wanted to take advantage of the fact that in some processes I could attack directly the couchdb to leverage the requests. The "validate_doc_read" feature is what would solve this problem but I am not sure when this would become viable.
salu2 On 09/27/2013 01:58 PM, Filippo Fadda wrote: > Hi Thorsten, > > I don't think it's a good idea, this solution doesn't scale. > > Are you programming a web app or something else? I'm asking because maybe the > solution is avoid the users db, implementing the business logic in your > application layer. > > -Filippo > > On Sep 27, 2013, at 12:37 PM, Thorsten Scherler wrote: > >> Hi all, >> >> meanwhile the patch for "validate_doc_read" is not applied I am studying >> different workarounds. >> >> One valid solution for our use case is to create a db for each user and >> store the user specific stuff in that db. >> That has the benefit that we can limit the access to that db with the >> standard security mechanism and we do not >> need to fall back to middleware logic. >> >> The biggest problem I see in the approach is that we need to know what >> is the max number of "user" db >> we can have in one instance. Regarding the size of this db it is >> expected to be a couple of smaller docs. >> >> Somebody has experience with that? Like rule of thumb do not deploy more >> then 10k databases in one instance ... >> >> TIA for any thoughts. >> >> salu2 >> >> -- >> Thorsten Scherler <scherler.at.gmail.com> >> codeBusters S.L. - web based systems >> <consulting, training and solutions> >> >> http://www.codebusters.es/ >> -- Thorsten Scherler <scherler.at.gmail.com> codeBusters S.L. - web based systems <consulting, training and solutions> http://www.codebusters.es/
