Is the proposal to calculate and store the md5 as a meta field, or to calculate md5(_rev, body) at request time? Doing this at request time would be very expensive for heavily loaded servers.
<\JamesM> > On Apr 8, 2016, at 7:28 AM, Garren Smith <[email protected]> wrote: > > I think having something like X-Couch-Document-Rev is a good idea. We might > have to warn in the docs that _local docs that header value will never > change. > >> On Fri, Apr 8, 2016 at 3:05 PM, Alexander Shorin <[email protected]> wrote: >> >> +1 if we also add X-Couch-Document-Rev so something that reflects the >> _rev value in HTTP headers. >> >> Currently, while Etag matches the _rev value, it makes quite handy >> feature for getting the document revisions without fetching whole the >> body. To not break this feature, we need to introduce something in >> place of old Etag behaviour to keep the balance. >> -- >> ,,,^..^,,, >> >> >>> On Fri, Apr 8, 2016 at 3:43 PM, Garren Smith <[email protected]> wrote: >>> Hi All, >>> >>> I would like to propose a change to how we generate the ETAG for a >> document >>> response. >>> >>> While working on COUCHDB-2978[1] we started looking at how etags were >>> generated when a document is requested. Currently the etag for a document >>> is the _rev. This causes a problem with _local documents as their >> revision >>> never changes also with documents where the user chooses the _rev. Both >> of >>> these can cause some caching issues. >>> >>> I would like to propose that the etag is generated from the body of the >>> response (typically the document), _rev and attachments. So for normal >>> documents the etag is md5(_rev, body, attachment) and for _local >> documents >>> it would be md5(_rev, body). This would make it a lot more consistent and >>> the etag would change when a document has changed. >>> >>> Cheers >>> Garren >>> >>> >>> >>> >>> >>> [1] https://issues.apache.org/jira/browse/COUCHDB-2978 >>
