From user-return-19880-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Tue Feb 21 13:16:45 2012 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 2512B9BE9 for ; Tue, 21 Feb 2012 13:16:45 +0000 (UTC) Received: (qmail 19078 invoked by uid 500); 21 Feb 2012 13:16:43 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 19041 invoked by uid 500); 21 Feb 2012 13:16:43 -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 19033 invoked by uid 99); 21 Feb 2012 13:16:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2012 13:16:43 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rogutes@googlemail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2012 13:16:35 +0000 Received: by eekc50 with SMTP id c50so2696863eek.11 for ; Tue, 21 Feb 2012 05:16:15 -0800 (PST) Received-SPF: pass (google.com: domain of rogutes@googlemail.com designates 10.14.48.77 as permitted sender) client-ip=10.14.48.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rogutes@googlemail.com designates 10.14.48.77 as permitted sender) smtp.mail=rogutes@googlemail.com; dkim=pass header.i=rogutes@googlemail.com Received: from mr.google.com ([10.14.48.77]) by 10.14.48.77 with SMTP id u53mr13167908eeb.0.1329830175610 (num_hops = 1); Tue, 21 Feb 2012 05:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to; bh=cS07RiVI0xpAqub5trdk4ZSIT86io6zPUBIoLMJ6L30=; b=RxfBe1sE140Q9InxlEknEjQf/ktqdv8KAwBNIzKQHP89hNVofBy3BP2Pchf4U8bXl5 3ShHKcUjaIUewiHPg2J26HV/vzzowEWZhDY/F1AjjFbUW398mmSWMVS2sD9w/56QSW7Z Ovm7v+3CRB5B6ns/vzBGduct4uhyeaFtUxaQs= Received: by 10.14.48.77 with SMTP id u53mr10524501eeb.0.1329830175532; Tue, 21 Feb 2012 05:16:15 -0800 (PST) Received: from urvas (78-62-122-124.static.zebra.lt. [78.62.122.124]) by mx.google.com with ESMTPS id o49sm90069408eeb.7.2012.02.21.05.16.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 05:16:13 -0800 (PST) Date: Tue, 21 Feb 2012 15:16:03 +0200 From: =?utf-8?Q?Rogut=C4=97s?= Sparnuotos To: user@couchdb.apache.org Subject: Re: possible compact bug in 1.1.1 Message-ID: <20120221131602.GA1158@urvas> Mail-Followup-To: user@couchdb.apache.org References: <9032450E6B3D8244858652FFFD6E29BC0294FC@OZWEX0202N2.msad.ms.com> <9032450E6B3D8244858652FFFD6E29BC02A825@OZWEX0202N2.msad.ms.com> <9032450E6B3D8244858652FFFD6E29BC02A8A0@OZWEX0202N2.msad.ms.com> <9032450E6B3D8244858652FFFD6E29BC10491A@OZWEX0202N2.msad.ms.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9032450E6B3D8244858652FFFD6E29BC10491A@OZWEX0202N2.msad.ms.com> X-Virus-Checked: Checked by ClamAV on apache.org Szabo, Viktor (2012-02-20 21:16): > Hi, > > An application we have is using bulk writes to insert objects into the database, and occasionally some > documents get lost. It turns out this happens for the very same reason described below. If we're > re-insering a doc using an id that has been deleted earlier, if the contents match the payload that was > saved when the id got used for the first time, the doc remains in "deleted" state and the client > gets a misleading response. This only happens when the database is compacted after the delete operation > is executed. > > I still feel that this is pretty nasty - what do you guys think? > > Looking at the reply coming from _bulk_docs, there's no way I can tell if I can read back my doc from the database or not. This is a bug and it would be nice if you could report it to JIRA. I can also reproduce it with the latest CouchDB version from git (and this seems not really related to _bulk_docs): alias curl='curl -H "Content-Type: application/json"' url="http://localhost:5984/database" 1 curl -X PUT $url 2 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 3 curl -X DELETE "$url/bug?rev=1-59414e77c768bc202142ac82c2f129de" 4 curl -X POST "$url/_compact" 5 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 6 curl -X GET "$url/bug" (bug here) 1 {"ok":true} 201 2 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}] 201 3 {"ok":true,"id":"bug","rev":"2-9b2e3bcc3752a3a952a3570b2ed4d27e"} 200 4 {"ok":true} 202 5 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}] 201 6 {"error":"not_found","reason":"deleted"} 404 CouchDB shouldn't report "ok" on step 5 and then go on to claim that the doc is deleted. Also, it seems to work on second try: 7 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 8 curl -X GET "$url/bug" 7 {"ok":true,"id":"bug","rev":"3-674f864b73df1c80925e48436e21d550"} 201 8 {"_id":"bug","_rev":"3-674f864b73df1c80925e48436e21d550","key":"value"} 200 -- -- Rogutės Sparnuotos