incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Gable <>
Subject Re: RESTful document structure
Date Mon, 11 Jul 2011 14:52:47 GMT
You're obviously free to do whatever you want, but I'd have it split like

design doc 1: documents that are users
design doc 2: documents that are requests
design doc 3: documents that are service providing users (or have
user.service_provider = true)

Or put another way, consider views to be methods and design docs to be
classes. Request.by_priority, Request.by_user(startkey=[userid, 0],
endkey=[userid, {}]), etc.

Since you can have as many design docs as you want and there's a performance
improvement (at the cost of disk space) of having multiple design docs, why
not do it this way?

On Mon, Jul 11, 2011 at 9:41 AM, Kevin R. Coombes <
> wrote:

> Having just started putting together a db where multiple design docs make
> sense (at least to me), I can perhaps offer an explanation. We are trying to
> use couch to track a certain class of service requests.
> Design doc 1:  All users can make requests, and they can see the status of
> their requests.
> Design doc 2: Only the people who actually provide service can look at the
> full queue and decide whether to accept a request (by assigning it to
> someone responsible for fulfilling the request) or declining a request (with
> an explanation).
> The basic views/interfaces used by the two groups of people are different,
> so it is actually easiest if the code is separated into differenty design
> documents.  Since we also tend to implement security through a proxy layer,
> it is also convenient to have a different class of URLs that can bre
> controlled by the proxy server, and the design docs make this easy:
>    /ourdb/_design/users
> is separate from
>    /ourdb/_design/workers
> and so we can put separate controls on who can access them.
> There is also a third design doc for administrators who can generate
> reports on how many requests have been received, how many have been acted
> on, etc. in any given time frame.
> To me, these do not represent separate apps...
>    -- Kevin
> On 7/10/2011 3:11 PM, Mark Hahn wrote:
>> you could make one single class (ClassToRuleThemAll, let's say) to
>> hold the data for every single data type you work with, but that's silly.
>> It's silly because there is a practical disadvantage in that every
>> instance would waste space for all the variables that would be needed.
>> I can't think of any practical advantage for having multiple design
>> docs unless multiple apps share a db.

Keith Gable
A+ Certified Professional
Network+ Certified Professional
Web Developer

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