From user-return-11818-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Aug 02 18:04:07 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 60209 invoked from network); 2 Aug 2010 18:04:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Aug 2010 18:04:07 -0000 Received: (qmail 54988 invoked by uid 500); 2 Aug 2010 18:04:06 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 54768 invoked by uid 500); 2 Aug 2010 18:04:05 -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 54760 invoked by uid 99); 2 Aug 2010 18:04:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 18:04:05 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.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 (athena.apache.org: domain of mikebeam@mac.com designates 17.148.16.103 as permitted sender) Received: from [17.148.16.103] (HELO asmtpout028.mac.com) (17.148.16.103) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 18:03:57 +0000 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iJ2ZmD3A4bLOLhspeAh2pw)" Received: from [10.0.1.5] (99-99-233-188.lightspeed.hstntx.sbcglobal.net [99.99.233.188]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L6J00D2YE5ZRXA0@asmtp028.mac.com> for user@couchdb.apache.org; Mon, 02 Aug 2010 11:03:37 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008020144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-08-02_07:2010-08-02,2010-08-02,1970-01-01 signatures=0 From: Michael Beam Subject: Appropriate use of batch=ok? Date: Mon, 02 Aug 2010 13:03:35 -0500 Message-id: <239F8AD7-FA18-417A-85AE-36C6E77328CE@mac.com> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1081) --Boundary_(ID_iJ2ZmD3A4bLOLhspeAh2pw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, CouchDB is used throughout an application that I work on, and I was thinking of using it for a new implementation of an old feature. The feature involves other applications reporting progress of "jobs" to a progress DB via documents that look like: { "_id":"a8baaee7963b4ee5893f0120514c4294", "_rev":"35-8735bcf3c66945932acb4d573166f741", "progress":0.87 } Since there may be potentially hundreds of processes updating their progress docs relatively frequently (say, one update every 10 seconds, maybe longer, maybe much longer) I figured this would be an ideal use case for batch=ok in the PUT request that applications use to update their job's progress to the database. However, I discovered that the rev is not returned (which makes sense), which means that for an app to update it's progress doc, it needs to get the rev through a separate HEAD request. In terms of overall load on the server, is anything gained by doing lots of updates via HEAD/PUT-batch=ok versus a standard PUT? Or, am I missing some other relevant aspect of Couch in my analysis of the problem? Thanks in advance, Mike --Boundary_(ID_iJ2ZmD3A4bLOLhspeAh2pw)--