Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jens@couchbase.com designates
 206.225.164.32 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
CC: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Wed, 18 Jan 2012 19:07:10 -0800
Subject: Re: Attachments and replication
Thread-Topic: Attachments and replication
Thread-Index: AczWV3H+PE7KrtnsTie/qHhkVwDtlQ==
Message-ID: <9BEF8BA9-0CB4-4C5B-8EED-414A73E04FAE@couchbase.com>
References: <4F177762.9030504@stevenringo.com>
 <CAKrexVKA5Fbywa4a1utyXr26Aq_S-zD93YWNzm+5jYsDiyrToA@mail.gmail.com>
In-Reply-To: 
 <CAKrexVKA5Fbywa4a1utyXr26Aq_S-zD93YWNzm+5jYsDiyrToA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

No, an attachment is stored only once in the DB file no matter how many rev=
isions it appears in. The attachment contents are only copied during compac=
tion.

--Jens     [via iPhone]

On Jan 18, 2012, at 6:22 PM, "CGS" <cgsmcmlxxv@gmail.com> wrote:

> Hi Steven,
>=20
> As far as I know, the attachments are still hardcoded in the document and
> so, if the document changes its revision, the new document inherits all t=
he
> fields (including its attachments). Therefore, the replication transfers
> again the attachment. I suppose this was the way to avoid the loss of the
> attachment in case of compaction.
>=20
> Relatively recently, there was a discussion to make an attachment to be
> held only once per database (or even maybe externally, don't remember
> exactly), but I have no knowledge of its outcome. Maybe someone more
> knowledgeable will be able to give you more details here.
>=20
> For the time being, my suggestion would be you to use external paths
> (usually, they are much smaller) and to transfer the files by an external
> script.
>=20
> CGS
>=20
>=20
>=20
>=20
> On Thu, Jan 19, 2012 at 2:52 AM, Steven Ringo <google@stevenringo.com>wro=
te:
>=20
>> Hi all,
>>=20
>> Assuming I have a document with an attachment and some fields, and that
>> this document has been replicated between source and target servers.
>>=20
>> {
>>  "_id": "**551ffd9dc43cb73c257628d8a31e9e**1f",
>>  "_rev": "4-**387d5d23b62e398421bddb10e16e74**0f",
>>  "foo": "bar",
>>  "baz": "quux",
>>  "published": false,
>>  "_attachments": {
>>      "photo.jpg": {
>>          "content_type": "image/jpeg",
>>          "revpos": 2,
>>          "digest": "md5-iOKjYGKWzEmEtMaqmYCtlA=3D=3D"**,
>>          "length": 3622469,
>>          "stub": true
>>      }
>>  }
>> }
>>=20
>> Let's say I change one of the fields on the source server; say "foo":
>> "bar" to "foo": "bar2". I then do a pull replication.
>>=20
>> Sniffing the packets, it seems to me the entire document is replicated,
>> including attachments. I was under the impression couchdb would be able =
to
>> replicate the document independently of the attachments.
>>=20
>> In other words couchdb would transfer just the "text/json" portion of th=
e
>> document and not the attachment, i.e. less than ~1 kbyte vs. a few
>> megebytes in this case.
>>=20
>> My experience seems to contradict my assumption. It looks like the diges=
t
>> and revpos fields are used for this, as mentioned here:
>> http://stackoverflow.com/**questions/1825117/what-is-the-**
>> revpos-value-used-for-in-**couchdb-attachments<http://stackoverflow.com/=
questions/1825117/what-is-the-revpos-value-used-for-in-couchdb-attachments>
>>=20
>> Is there something I am missing or perhaps a configuration option I am n=
ot
>> setting properly?
>>=20
>> Thanks.
>>=20
>>=20
>>=20
>>=20
>>=20