Hey Tim,
looks like you have found a bug :) Could you file a report
(https://issues.apache.org/jira/browse/COUCHDB)? A JavaScript test for
reproducing this problem is also very welcome (and will help to prevent
regression).
Best
Sebastian
On 04.10.2010, at 04:18, Tim Hart wrote:
> 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
