Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 94695 invoked from network); 6 Aug 2008 15:31:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Aug 2008 15:31:28 -0000 Received: (qmail 71780 invoked by uid 500); 6 Aug 2008 15:31:27 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 71466 invoked by uid 500); 6 Aug 2008 15:31:26 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 71455 invoked by uid 99); 6 Aug 2008 15:31:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2008 08:31:26 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dnew@san.rr.com designates 75.180.132.121 as permitted sender) Received: from [75.180.132.121] (HELO cdptpa-omtalb.mail.rr.com) (75.180.132.121) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2008 15:30:30 +0000 Received: from [192.168.0.10] (really [76.88.29.4]) by cdptpa-omta06.mail.rr.com with ESMTP id <20080806152956.JMDH9085.cdptpa-omta06.mail.rr.com@[192.168.0.10]> for ; Wed, 6 Aug 2008 15:29:56 +0000 Message-ID: <4899C375.8070804@san.rr.com> Date: Wed, 06 Aug 2008 08:29:57 -0700 From: Darren New User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: couchdb-user@incubator.apache.org Subject: Re: Optionally including docs in view results References: <48974B09.5080807@inflatablecookie.com> <489752DF.2030603@inflatablecookie.com> <489775CC.3010707@inflatablecookie.com> <64a10fff0808041442r6d864058rd923b494207a7882@mail.gmail.com> <9DF72862-153C-4752-92E0-5DA4EF65CDE1@blit.com> <86423A2B-CB26-45F8-9998-532B8B0FE36B@blit.com> <489989C7.9030400@inflatablecookie.com> In-Reply-To: <489989C7.9030400@inflatablecookie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Tom Wright wrote: > _bulk_get > _bulk_insert > _bulk_update > _bulk_delete It might be useful, also, to think in terms of a meta-level of naming, even inside the JSON. For example, if documents are modified with a PUT, then rather than having _bulk_docs take an array with a tag of "docs" on it, have _bulk_docs take an array with a tag of "PUT" on it. In other words, have a one-to-one mapping from the RESTful interface to the _bulk* interface(s), rather than having each operation be ad hoc. I've found in the past this makes things (a) much easier to describe and learn and (b) much easier to extend. Something like setting the deleted flag=true to delete it in bulk docs and using a different verb in REST is the sort of thing that leads to needing _tag syntax in the first place. Just a thought on the design. -- Darren New / San Diego, CA, USA (PST) Ever notice how people in a zombie movie never already know how to kill zombies? Ask 100 random people in America how to kill someone who has reanimated from the dead in a secret viral weapons lab, and how many do you think already know you need a head-shot?