couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <kevin.r.coom...@gmail.com>
Subject Re: RESTful document structure
Date Mon, 11 Jul 2011 14:59:47 GMT
I like the idea that "views are methods and design docs are classes".  
I'm just not convinced that "classes" has to map directly to 
classes/subsets of documents.

Both classes of people who use the system (requesters and service 
providers) deal with the same set of documents: requests.   And the vast 
majority of documents in the database will be requests.  What differs is 
the set of actions/methods that different classes of people can or 
should perform with those documents.  So I still think that splitting 
the design docs to match the main classes of people who interact with 
the system (with the views as their methods) is a reasonable way to do 
things....
     Kevin

On 7/11/2011 9:52 AM, Keith Gable wrote:
> You're obviously free to do whatever you want, but I'd have it split like
> so:
>
> 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<kevin.r.coombes@gmail.com
>> 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.
>>>
>>>
>

Mime
View raw message