incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Ringo <goo...@stevenringo.com>
Subject Re: Attachments and replication
Date Thu, 19 Jan 2012 03:40:04 GMT
Jens,

In terms of what you describe, I am definitely getting undesired behaviour.

I am using CouchDB 1.1.1 on Mac OS replicating from the same instance, 
as well as IrisCouch (1.1.1 on Ubuntu, I think).

Ultimately need this to work on Mobile couchbase, but experimenting with 
replication locally first.

I ran:

$ curl -H 'Content-Type: application/json' -X POST 
http://localhost:5984/_replicator -d '{"source": 
"http://127.0.0.1:5984/dslcollection", "target": 
"http://127.0.0.1:5984/dslcollection-ios"}'
{"ok":true,"id":"f36d2bb4d5bdfd3813eb706130001632","rev":"1-c414a5d61d7164c231777472d087ea56"}

Couchdb logging shows (with packet sniffer to tell me how big the 
request/responses are:

[info] [<0.2693.2>] 127.0.0.1 - - 'GET' 
/dslcollection/551ffd9dc43cb73c257628d8a31e9e1f/88e2a3606296cc4984b4c6aa9980ad94.jpg?rev=10-d5aa0c311cbfac1b8c7309163625c5d0

200
(This is a 3.5MB GET)

[info] [<0.2692.2>] 127.0.0.1 - - 'PUT' 
/dslcollection-ios/551ffd9dc43cb73c257628d8a31e9e1f?new_edits=false 201
(3.5MB PUT payload)

Thanks,

Steve










--
Steven Ringo

Jens Alfke wrote:
> No, an attachment is stored only once in the DB file no matter how many revisions it
appears in. The attachment contents are only copied during compaction.
>
> --Jens     [via iPhone]
>
> On Jan 18, 2012, at 6:22 PM, "CGS"<cgsmcmlxxv@gmail.com>  wrote:
>
>> Hi Steven,
>>
>> 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 the
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> CGS
>>
>>
>>
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message