diffs - if we can get the transport right, they'd make a great use case. The problem, as has been discussed in the archives, is a canonical json format, or a json diff format, neither of which are obvious to implement.
for attachments, binary diffs would be interesting, I wonder how usable git's format would be for us? On Wed, Nov 26, 2008 at 5:14 PM, Jan Lehnardt <[EMAIL PROTECTED]> wrote: > > On 26 Nov 2008, at 12:40, Dan wrote: > >> Here is a conversation I had on the IRC channel #couchdb on this subject >> on >> november 24, 2008 (2 days ago). Hope this helps! > > I kinda don't like IRC quotes floating around, but hey, I didn't put up any > disclaimers either. Take the following with a grain of salt :) > > >> (04:01:26 PM) dsimard: I just wanted to know if an attachment changes, >> will >> the new revision contain just the "diff" with the old attachment or the >> complete attachment? >> (04:01:49 PM) jan____: complete attachment. diffs are the devil >> (04:03:08 PM) dsimard: damn... all fields of a document are stored as a >> full >> document? >> (04:03:18 PM) dsimard: I really thought that diffs were used >> (04:03:35 PM) jan____: no, no diffs. diffs are the devil >> (04:04:14 PM) dsimard: ok, could you elaborate on the evilness of diffs? >> (04:04:44 PM) dsimard: I just want to know more about it >> (04:05:04 PM) jan____: dsimard: you need to keep diffs around forever to >> construct the latest live doc. this totally conflicts with the couchdb >> storage model which uses full representations of each revision. >> (04:05:04 PM) dsimard: or if you have a good link about it >> (04:05:35 PM) jan____: >> http://incubator.apache.org/couchdb/docs/overview.html >> (04:05:36 PM) jan____: that one >> >> In my opinion, it would be a great addition to couchdb. But still, I can't >> wait to use it on my next project. > > > > >> >> >> >> On Wed, Nov 26, 2008 at 3:25 PM, Liam Staskawicz <[EMAIL PROTECTED]> wrote: >> >>> >>> On Nov 26, 2008, at 12:20 PM, Noah Slater wrote: >>> >>> On Wed, Nov 26, 2008 at 09:57:24AM -0800, Liam Staskawicz wrote: >>>> >>>>> When updating a document, is there any notion of submitting a partial >>>>> update? >>>>> It seems like being able to specify that only some subset of the fields >>>>> in a >>>>> document should be updated would offer some efficiency benefits. I >>>>> guess >>>>> I >>>>> had in mind some scenario where CouchDB would create the updated record >>>>> by >>>>> merging the existing revision with the new info and saving the updated >>>>> revision, but I'm still new to CouchDB so I don't have a good sense of >>>>> whether >>>>> this tramples on any important concepts. >>>>> >>>> >>>> Nope, CouchDB does not support this at the moment. If you want to make >>>> an >>>> update >>>> you have to send the entire document each time. >>>> >>>> There is some discussion among CouchDB users and developers about the >>>> benefits >>>> of partial updates but it seems the real sticking point so far is >>>> deciding >>>> on >>>> the mechanism for enabling this. It seems the rough consensus at this >>>> point is >>>> that whatever method we use be something that is standardised, either >>>> through a >>>> standards body or de facto within the larger JSON community. >>>> >>> >>> Thanks for the response - and yeah, this is not a sticking point at the >>> moment but as systems start to ramp up this seems like a pretty good way >>> to >>> make the back and forths much more efficient. Will be looking forward >>> to >>> this being introduced at some point. >>> >>> Liam >>> > > -- Chris Anderson http://jchris.mfdz.com
