Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of
 sebastiancohnen@googlemail.com designates 209.85.215.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=f/Cekt55ZA4N2gOY7tpRHQGXL2TjodEne4dGXXdIGYj2uoRnV24/dFNA35iNUltMiG
         FMYnJMQqxtSRJntM85t+zz+1thp9LK6Kb95CKDgS2Yl/iOzCm4mn3DECaPEFxaGr0ABv
         +Q0E1H7AOnp+0zZrxq5/Nf6d1h9G4SSUZUhEE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: View queries and etags
From: Sebastian Cohnen <sebastiancohnen@googlemail.com>
In-Reply-To: <E6B5236B-F45E-4343-BB0E-A4D73766B625@me.com>
Date: Mon, 4 Oct 2010 10:03:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <72DBDE66-1BD8-41DB-95CA-51587EAD5231@googlemail.com>
References: <E6B5236B-F45E-4343-BB0E-A4D73766B625@me.com>
To: user@couchdb.apache.org

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,
>=20
> 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.
>=20
> 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:
>=20
> Functional test setup:
>=20
> 1. create '/test_db'
> 2. insert view:
>=20
> function(doc) {
>  var recordType =3D doc.type;
>    for(var key in doc)
>      if(/.+_id$/.test(key)){
>        emit({type:recordType, fKey:doc[key]}, null);
>      }
>  }
> }
>=20
> 3. insert document A (via put)
> {
>  _id:'parent_id', //I wanted a known ID for convenience sake
>  type:'parent'
> }
>=20
> 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
> }
>=20
> 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:=20
>=20
> =
http://localhost:5984/test_db/_design/fetch/_view/fetchKeys?key=3D{%22type=
%22%3A%22child%22%2C%22fKey%22%3A%22parent_id%22}&include_docs=3Dtrue
>=20
> 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=3Dtrue', the results of the query are never the same. To =
illustrate:
>=20
> 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":"par=
ent_id"},"value":null,"doc":{"_id":"121026820a1c1454e82930085604b15a","_re=
v":"1-c2ad8daac622eea701f0c62dfa023ea9","parent_id":"parent_id","type":"ch=
ild"}}
> ]}
>=20
> 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":"par=
ent_id"},"value":null,"doc":{"_id":"121026820a1c1454e82930085604be87","_re=
v":"1-c2ad8daac622eea701f0c62dfa023ea9","parent_id":"parent_id","type":"ch=
ild"}}
> ]}
>=20
> 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
>=20
> first run:
> passed - expected childID "foo", actual child id "foo"
>=20
> second run:
> failed expected childID "bar", but was "foo"
>=20
> 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.
>=20
> 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.
>=20
> Tim