From user-return-17098-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Jul 11 14:53:19 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F30834D2E for ; Mon, 11 Jul 2011 14:53:18 +0000 (UTC) Received: (qmail 52062 invoked by uid 500); 11 Jul 2011 14:53:17 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 51995 invoked by uid 500); 11 Jul 2011 14:53:16 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 51987 invoked by uid 99); 11 Jul 2011 14:53:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 14:53:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ziggythehamster@gmail.com designates 209.85.161.44 as permitted sender) Received: from [209.85.161.44] (HELO mail-fx0-f44.google.com) (209.85.161.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jul 2011 14:53:08 +0000 Received: by fxe6 with SMTP id 6so3929095fxe.31 for ; Mon, 11 Jul 2011 07:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=XpznWLwouVV/dTQ0vBiHwMwdu1g08gh/POC/B1wCJ38=; b=xwwV1Rak0a0bsbo5h2MwSDQGm8lguaU1vFXzaWLksTJhTP9Yhimzjm/HTxPmXMF62D XzaOOIridBI4YDwsTK8pIPm+kgm+08qFsXRR3Fq+fD0WIDDjSLUyyMKAiKdcPqWFUdOv O098bfJyJMFXIGoTaALHWkhb4M/h+IA4cuPHI= MIME-Version: 1.0 Received: by 10.223.75.139 with SMTP id y11mr7935803faj.133.1310395967890; Mon, 11 Jul 2011 07:52:47 -0700 (PDT) Sender: ziggythehamster@gmail.com Received: by 10.223.111.15 with HTTP; Mon, 11 Jul 2011 07:52:47 -0700 (PDT) In-Reply-To: <4E1B0B9A.6040502@gmail.com> References: <4E1B0B9A.6040502@gmail.com> Date: Mon, 11 Jul 2011 09:52:47 -0500 X-Google-Sender-Auth: EU-vKUZydk8txokB-xwZgzIEfpM Message-ID: Subject: Re: RESTful document structure From: Keith Gable To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0015174c40662e668d04a7cc56ae X-Virus-Checked: Checked by ClamAV on apache.org --0015174c40662e668d04a7cc56ae Content-Type: text/plain; charset=ISO-8859-1 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 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 --0015174c40662e668d04a7cc56ae--