couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: [Proposal] Change etag calculation
Date Mon, 11 Apr 2016 16:11:18 GMT
Cool. I’m a little confused about the MD5 for regular docs discussion. What’s the driving
force behind switching away from revisions as ETags. Is it

1) Users can break this by setting their own revisions
2) Documents with identical bodies but different revisions should be cacheable

In case #1 a user operating at this level potentially breaks quite a bit more than the caching
mechanism, doesn’t she? I’d need to think through the full ramifications but I’d love
to see investment in the standardization of the revision generation algorithm as we discussed
in a recent thread, and then maybe be a bit more strict around the revision IDs that we accept
with new_edits=false.

Case #2 also feels broken to me, we probably can’t be returning documents from a cache with
the wrong revision ID.

Sorry if I’m missing the crux of the argument here.

Adam

> On Apr 11, 2016, at 10:43 AM, Garren Smith <garren@apache.org> wrote:
> 
> Thanks for the feedback. For now I will proceed with getting the _local
> fixes then. Then we can look at a performant way of doing the md5 for
> regular docs.
> 
> Cheers
> Garren
> 
> On Sat, Apr 9, 2016 at 10:18 AM, Robert Newson <rnewson@apache.org> wrote:
> 
>> The original patch from garren calculated the md5(body) at query time.
>> This was fine for just local docs since fetching then is rare.
>> 
>> I'm +1 on the proposal and agree we need to precalculate the etag for
>> regular docs.
>> 
>>> On 8 Apr 2016, at 19:01, Alexander Shorin <kxepal@gmail.com> wrote:
>>> 
>>>> On Fri, Apr 8, 2016 at 8:55 PM, Mutton, James <jmutton@akamai.com>
>> wrote:
>>>> 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.
>>> 
>>> Good point and concern. This is not a new meta field, just a Etag
>>> header value. And obliviously, there should be the way to not generate
>>> Etag value if it eventually the same as the _rev field value (I think
>>> it's good idea to let them share the same algo).  Technically, this
>>> could be done by looking on what kind of edit happened: interactive or
>>> not.
>>> 
>>> --
>>> ,,,^..^,,,
>> 
>> 


Mime
View raw message