Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 68530 invoked from network); 2 Jun 2010 18:34:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Jun 2010 18:34:07 -0000 Received: (qmail 48784 invoked by uid 500); 2 Jun 2010 18:34:07 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 48572 invoked by uid 500); 2 Jun 2010 18:34:07 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 48564 invoked by uid 99); 2 Jun 2010 18:34:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 18:34:07 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 18:34:04 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o52IXg7K012770 for ; Wed, 2 Jun 2010 18:33:43 GMT Message-ID: <1968938.139211275503622959.JavaMail.jira@thor> Date: Wed, 2 Jun 2010 14:33:42 -0400 (EDT) From: "Jan Lehnardt (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Closed: (COUCHDB-294) in validation functions, new_doc does not contain the rev that was sent in the request In-Reply-To: <672331758.1237389950493.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/COUCHDB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-294. -------------------------------- Resolution: Invalid The behaviour looks correct to me. The validation function runs before the document is written to the database which is when it gets the new rev id. Feel free to reopen the issue with a test script that demonstrates the erroneous behaviour (bonus points for a patch to the JavaScript or etap test suite :). > in validation functions, new_doc does not contain the rev that was sent in the request > --------------------------------------------------------------------------------------- > > Key: COUCHDB-294 > URL: https://issues.apache.org/jira/browse/COUCHDB-294 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface > Affects Versions: 0.9 > Environment: ubuntu > Reporter: Tim > > The new_doc in a validation does not contain the revision that you sent in the post/put request. > In this log, each block contains a log of > [info] old_doc > [info] new_doc > [info] request > {{{ > new doc > ------- > [info] [<0.68.0>] OS Process Log Message: null > [info] [<0.68.0>] OS Process Log Message: {"_id": "wibble","_rev": "1-3141321355","_revisions": {"start": 1,"ids": ["3141321355"]}} > [info] [<0.935.0>] 127.0.0.1 - - 'PUT' /conflict/wibble 201 > update 1st rev, no conflict > --------------------------- > [info] [<0.68.0>] OS Process Log Message: {"_id": "wibble","_rev": "1-3141321355","_revisions": {"start": 1,"ids": ["3141321355"]}} > [info] [<0.68.0>] OS Process Log Message: {"_id": "wibble","_rev": "2-1123114967","_revisions": {"start": 2,"ids": ["1123114967","3141321355"]}} > [info] [<0.977.0>] 127.0.0.1 - - 'POST' /conflict/_bulk_docs 201 > As you can see on this second request, the document sent will have had a rev of "1-3141321355" but in the validation function the new_doc has the rev that is just about to be written to disk.. I cannot see a way to access the rev that was sent across the request. > }}} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.