Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 22 Sep 2014 16:00:35 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12743207.1411397306000.94309.1411401635877@Atlassian.JIRA>
In-Reply-To: <JIRA.12743207.1411397306000@Atlassian.JIRA>
References: <JIRA.12743207.1411397306000@Atlassian.JIRA>
 <JIRA.12743207.1411397306554@arcas>
Subject: [jira] [Commented] (COUCHDB-2338) Reproduceable document revision
 hash calculation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143338#comment-14143338 ] 

Alexander Shorin commented on COUCHDB-2338:
-------------------------------------------

> The "completely random" assertion 
True, I didn't read case clause carefully.

> Reproduceable document revision hash calculation
> ------------------------------------------------
>
>                 Key: COUCHDB-2338
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2338
>             Project: CouchDB
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: Database Core
>            Reporter: Alexander Shorin
>
> Current document revision hash implementation is very Erlang-specific:
> {code}
> new_revid(#doc{body=Body,revs={OldStart,OldRevs},
>         atts=Atts,deleted=Deleted}) ->
>     case [{N, T, M} || #att{name=N,type=T,md5=M} <- Atts, M =/= <<>>] of
>     Atts2 when length(Atts) =/= length(Atts2) ->
>         % We must have old style non-md5 attachments
>         ?l2b(integer_to_list(couch_util:rand32()));
>     Atts2 ->
>         OldRev = case OldRevs of [] -> 0; [OldRev0|_] -> OldRev0 end,
>         couch_util:md5(term_to_binary([Deleted, OldStart, OldRev, Body, Atts2]))
>     end.
> {code}
> All the bits in code above are trivial for every programming language except {{term_to_binary}} function implementation: to make it right you need dive deeper into Erlang. I have nothing against it, Erlang is cool, but this implementation specifics makes whole idea to reproduce document revision as untrivial complex operation.
> Rationale: you want to build CouchDB compatible storage on different from Erlang technology stack that will "sync" with CouchDB without worry about non-matched revisions for the same content with the same modification history done in different "compatible" storages.
> P.S. Oh, yes, if you updates attachmets (add/del) revision becomes completely random. Moreover, if you just updates attachment for document there is some specific about revision calculation I don't recall now, but that would be easily notice by looking what the specified function takes on call.
> P.P.S. via https://twitter.com/janl/status/514019496110333952


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)