couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: -- Revision ID Calculation -- and -- Request for edit permissions on wiki --
Date Tue, 06 Mar 2012 16:01:10 GMT
It's typically the uncompressed byte stream (and un-base64 encoded),
though I think there's a path where it's the compressed stream
instead.

Yes, _attachments will be returned in the document body (along with
other special fields like _id and _rev) but the bodies will not
normally be present (they are so-called 'stubs'), though you can ask
for them.

While the rev calculation is unlikely to significantly change it is
not frozen, has changed in the past, is an internal detail, and not
part of the published and stable API. Since it's not necessary to
replicate the logic of this to build a compatible store, I urge
caution.

B.


On 6 March 2012 15:43, Davies, Owain <Owain.Davies@baesystemsdetica.com> wrote:
> Hi, It my wikiname is OwainDavies
>
> I figured out in my first version that the hash part of the rev id was
> an opaque string, but I wanted consistency of behaviour when I
> create/modify documents offline (where I calculate the revision id) and
> online (where it is submitted to the store directly and it assigns the
> revision id)?
>
> Currently my application does not use attachments but it will do in the
> future.
>
> When you say the you take an md5 of the file, what do you mean?
>        A.      Is it an md5 of the uncompressed byte stream
>        B.      An md5 of the text of the BASE64 encoded data.
>        C.      Something else.
>
> Also is the _attachments field included in the document body (are any
> special fields ever included in the document body?
>
> A lot questions I know, but thanks for any info?
>
>
> Owain
>
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 06 March 2012 15:29
> To: dev@couchdb.apache.org
> Subject: Re: -- Revision ID Calculation -- and -- Request for edit
> permissions on wiki --
>
> Presumably you're reading this;
>
> 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.
>
> Which, basically, means we add in the md5's of the attachments if we
> have them (and a random value if we don't).
>
> In any case, you don't need to slavishly reimplement the current _rev
> algorithm to interoperate correctly. The previous revision calculation
> was just a random value, after all.
>
> If you include your wiki username I can grant you edit access.
>
> B.
>
> P.S Who in the world would think of printing an email?
>
> On 6 March 2012 14:58, Davies, Owain <Owain.Davies@baesystemsdetica.com>
> wrote:
>> Hi,
>>
>> I have just joined this list. I am using CouchDB to do an offline web
>> app. I am having to re-implement some of the logic for conflict
>> detection, win determination and replication. I have implemented a
>> dojo.store that represents that CouchDB API, and am working on the
>> offline versions using IndexDB and WebSQL as the persistence provider.
>>
>> First off, please could somebody let me have edit permissions to the
>> wiki. I am finding lots of undocumented features, or features
>> documented in one place but not another. A prime example is
>> _changes?style=all_docs which has taken me some time to discover. Of
>> course, one I knew what it was called I found it documented in the
>> couchdb guide. Anyhow, I digress, if I get edit permissions I will
>> endeavour to record my changes.
>>
>> Second, can somebody please tell me how the revision id for documents
>> with attachments are calculated. I have produced a JavaScript module
>> that consistently calculates the revision of documents without
>> attachments. I had to reverse engineer erlangs term_to_binary
>> function, which is actually quite tricky. But I do not know erlang and
>
>> I do not understand how the Atts2 term is calculated. Any help?
>>
>> Kind regards,
>>
>> Owain
>>
>>
>> Please consider the environment before printing this email.
>>
>> This message should be regarded as confidential. If you have received
> this email in error please notify the sender and destroy it immediately.
>>
>> Statements of intent shall only become binding when confirmed in hard
> copy by an authorised signatory.
>>
>> The contents of this email may relate to dealings with other companies
> under the control of BAE Systems plc details of which can be found at
> http://www.baesystems.com/Businesses/index.htm.
>>
>> Detica Limited is a BAE Systems company trading as BAE Systems Detica.
>> Detica Limited is registered in England and Wales under No: 1337451.
>> Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP,
> England.
>>
> Please consider the environment before printing this email.
>
> This message should be regarded as confidential. If you have received this email in error
please notify the sender and destroy it immediately.
>
> Statements of intent shall only become binding when confirmed in hard copy by an authorised
signatory.
>
> The contents of this email may relate to dealings with other companies under the control
of BAE Systems plc details of which can be found at http://www.baesystems.com/Businesses/index.htm.
>
> Detica Limited is a BAE Systems company trading as BAE Systems Detica.
> Detica Limited is registered in England and Wales under No: 1337451.
> Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
>

Mime
View raw message