From user-return-13045-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Oct 04 02:19:38 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 9942 invoked from network); 4 Oct 2010 02:19:38 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Oct 2010 02:19:38 -0000 Received: (qmail 56495 invoked by uid 500); 4 Oct 2010 02:19:37 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 56397 invoked by uid 500); 4 Oct 2010 02:19:36 -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 56388 invoked by uid 99); 4 Oct 2010 02:19:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Oct 2010 02:19:36 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tjhart@me.com designates 17.148.16.100 as permitted sender) Received: from [17.148.16.100] (HELO asmtpout025.mac.com) (17.148.16.100) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Oct 2010 02:19:28 +0000 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XZ4NVi6FZ3K4+goGKC7kvQ)" Received: from [10.0.1.5] (c-68-52-241-216.hsd1.tn.comcast.net [68.52.241.216]) by asmtp025.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0L9Q00A3MUFKMOB0@asmtp025.mac.com> for user@couchdb.apache.org; Sun, 03 Oct 2010 19:18:59 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-10-04_01:2010-10-04,2010-10-04,1970-01-01 signatures=0 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-1010030196 From: Tim Hart Subject: View queries and etags Date: Sun, 03 Oct 2010 21:18:56 -0500 Message-id: To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1081) --Boundary_(ID_XZ4NVi6FZ3K4+goGKC7kvQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi all, Had a bit of trouble with etags and my browser cache tonight. In short, the etag was always the same in a circumstance where I assumed it wouldn't. Here are the details. I'm writing some functional tests that create a couchdb database, a view document, insert some documents, and then execute various tests against my own client javascript code. One of my tests would pass once, and then regularly fail without any change to the client code. The issue was the browser cache. Here are the details: Functional test setup: 1. create '/test_db' 2. insert view: function(doc) { var recordType = doc.type; for(var key in doc) if(/.+_id$/.test(key)){ emit({type:recordType, fKey:doc[key]}, null); } } } 3. insert document A (via put) { _id:'parent_id', //I wanted a known ID for convenience sake type:'parent' } 3. insert document B (via post, because I don't care what the ID would be) { type:'child', parent_id:'parent_id' //using my known ID } OK - setup is complete. I've verified several times that the setup works as expected. The test that caused issues with the browser cache was testing my code that dynamically builds a query against the view. The anticipated query in this case looks like this: http://localhost:5984/test_db/_design/fetch/_view/fetchKeys?key={%22type%22%3A%22child%22%2C%22fKey%22%3A%22parent_id%22}&include_docs=true What's happening is, the etag of the response to this query is always the same. My problem that in this case, since I'm including 'include_docs=true', the results of the query are never the same. To illustrate: First run through the test, the results of the query is: Header: etag: "7BD040ILHVQHCY0L8ER5DW2RG" date: Mon, 04 Oct 2010 02:02:52 GMT server: CouchDB/1.0.1 (Erlang OTP/R14B) content-length: 0 Body: {"total_rows":1,"offset":0,"rows":[ {"id":"121026820a1c1454e82930085604b15a","key":{"type":"child","fKey":"parent_id"},"value":null,"doc":{"_id":"121026820a1c1454e82930085604b15a","_rev":"1-c2ad8daac622eea701f0c62dfa023ea9","parent_id":"parent_id","type":"child"}} ]} The teardown deletes the database. I run the same test again, the parent has the same id, but the child gets a new one. The query is the same, and the index of the response looks the same, although the document itself is different. Here's the results of the second run: Header: etag: "7BD040ILHVQHCY0L8ER5DW2RG" date: Mon, 04 Oct 2010 02:07:27 GMT server: CouchDB/1.0.1 (Erlang OTP/R14B) content-length: 0 Body: {"total_rows":1,"offset":0,"rows":[ {"id":"121026820a1c1454e82930085604be87","key":{"type":"child","fKey":"parent_id"},"value":null,"doc":{"_id":"121026820a1c1454e82930085604be87","_rev":"1-c2ad8daac622eea701f0c62dfa023ea9","parent_id":"parent_id","type":"child"}} ]} My test keeps failing because it's anticipating the ID of the new 'child' row. The issue is that since the etag is the same, my browser cache takes over and returns the 'old' row to the javascript code. I've verified this by simply clearing my browser cache and rerunning my same, unaltered scripts. If I clear the browser cache between each run, it passes. Otherwise, it passes the first run after the cache clear, and fails every subsequent test. Each subsequent failure clearly shows that my code 'received' the ID child row during my first passing run, even though the insert captured the new ID, so first run: passed - expected childID "foo", actual child id "foo" second run: failed expected childID "bar", but was "foo" This feels to me like a case where the current algorithm for the etag isn't quite precise enough. Would it be reasonable to assume that if the query itself included the 'include_docs' param, then the etag algorithm should take that data into consideration? Actually in my case, simply taking the id field into consideration would solve my problem. For the time being, I've modified my test to fetch a UUID for the parent document. This makes the view row, and subsequent etag, unique for each query. Tim --Boundary_(ID_XZ4NVi6FZ3K4+goGKC7kvQ)--