couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ramirez <>
Subject Re: Document Updates
Date Thu, 13 Nov 2008 17:14:47 GMT
If I begin breaking up my documents into related documents aren't I just creating a relational


----- Original Message ----
From: Damien Katz <>
Sent: Thursday, November 13, 2008 10:00:44 AM
Subject: Re: Document Updates

I was planning on something similar this for field and attachment level replication, where
only the fields or attachments that are changed are replicated. With the scheme I'm thinking
of, it's possible to have it incremental at any nested level of the doc tree, but I'm not
sure the extra overhead is worth doing it beyond the root fields.

However, Michael's concern of the document getting larger and the app getting slower still
applies, the document must still be loaded into memory on the server and the diffs applied,
and the complete doc will need to be loaded into memory for view indexing too. Michael, regardless
of the diff updates, I'm thinking you need to break you document up into multiple documents.


On Nov 13, 2008, at 11:40 AM, Ayende Rahien wrote:

> I think that this should be pretty easily done using:
> a) well defined pretty format output
> b) standard diff
> The reason for (a) is that you need this to get line breaks, which are
> critical to diffing correctly.
> On Thu, Nov 13, 2008 at 6:38 PM, Noah Slater <> wrote:
>> On Thu, Nov 13, 2008 at 08:30:17AM -0800, Michael Ramirez wrote:
>>> Will this cause bandwidth issues when updating large documents if only a
>>> single field changes. I am afraid that as my documents grow larger my app
>> gets
>>> slower.
>> I for one am interested to hear JSON diff proposals. I think this would
>> make a
>> great addition to CouchDB. As best I can tell, this should really be done
>> as an
>> external standardisation effort so the whole community could benifit. I
>> don't
>> think using JavaScript to set the document attributes is a very good
>> solution to
>> this. An entirely new Media Type is needed, IMHO.
>> --
>> Noah Slater,


View raw message