You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@couchdb.apache.org by Johnny Weng Luu <jo...@gmail.com> on 2011/07/09 20:39:51 UTC

RESTful document structure

Since CouchDB is implementing a RESTful API, doesn't that mean I wanna put
all documents of the same type in their own database?

eg.

POST http://localhost/users
GET http://localhost/users/1
PUT http://localhost/users/1
DELETE http://localhost/users/1

POST http://localhost/threads
GET http://localhost/threads/1
PUT http://localhost/threads/1
DELETE http://localhost/threads/1

Rather than putting them all in one big database (http://localhost/my_app).

Doesn't a 100% RESTful approach mean that the former is more correct?

Re: RESTful document structure

Posted by Jason Smith <jh...@iriscouch.com>.

On Mon, Jul 11, 2011 at 3:11 AM, Mark Hahn <ma...@boutiquing.com> 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.

CQS uses multiple design documents which are machine-generated.

https://github.com/iriscouch/cqs

You get common access controls, but each queue can be created,
modified, or deleted independently, without affecting the others. In
my deployments, each worker has two queues (2 ddocs), high-priority
and low-priority. Indeed, the real "application" is a distributed
service, built from multiple workers, performing a common task.

I am not satisfied with this architecture. It bothers me to know that
dozens of validation functions execute for each update. Also, if I
change the design doc code, I must re-deploy dozens of times. Changing
validate_doc_update() code is a nightmare. But ultimately, it is a
trade-off and I still feel the benefits outweigh the limitations.

-- 
Iris Couch

Re: RESTful document structure

Posted by "Kevin R. Coombes" <ke...@gmail.com>.

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.
>>>
>>>
>

Re: RESTful document structure

Posted by Keith Gable <zi...@ignition-project.com>.

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.
>>
>>


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