couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burobjorn <burobj...@gmail.com>
Subject Re: partial/diff updates?
Date Thu, 27 Nov 2008 17:53:48 GMT
I like this approach.

This also creates the possibility to benchmark and compare the diff
methodology versus a full update. Would it be possible then to use
'standard' text diffs as well, without taking into account that we're
dealing with json?

All the best,
grtz
BjornW


* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship

Concordiastraat 68-126
3551 EM Utrecht
The Netherlands

phone: +31 6 49 74 78 70
http://www.burobjorn.nl


Timo Isokoski wrote:
> Is this talk about the "diff" feature related to
> 
> a) How CouchDB physically stores the data on disk
> b) How data is transmitted between the client and CouchDB
> 
> In case a) I think diffs are the devil and it goes aganist the simplicity of
> CouchDB:s inner workings. In case b), wouldn't it be easy to implement some
> kind of a prototype of this feature as a "proxy server" on top of CouchDB.
> The proxy could route the normal requests directly to CouchDB and the actual
> diff requests could be handled like this:
> 1. GET the original document from Couch
> 2. Apply diff
> 3. PUT the modified document back to the Couch
> 
> The functionality can then be integrated into CouchDB inself if the
> prototype works well and and people start using it.
> 
> 
> -Timo
> 
> 
> 
> 2008/11/27 Antony Blakey <antony.blakey@gmail.com>
> 
>> On 27/11/2008, at 10:10 PM, Noah Slater wrote:
>>
>>  On Thu, Nov 27, 2008 at 08:45:18PM +1030, Antony Blakey wrote:
>>>> * JPath its self is a nebulous concept.
>>>> In what sense do you think the concept is nebulous?
>>>>
>>> It lacks an RFC. :)
>>>
>> I didn't realize that JSON had an RFC! Now that I've read it, I think that
>> this statement:
>>  "A JSON text is a serialized object or array."
>> which dominates this subsequent statement:
>>  "The names within an object SHOULD be unique."
>> clearly resolves the ambiguity discussed in a previous thread regarding
>> duplicate hash keys, in the manner that I suggested. Namely, duplicate keys
>> are not allowed because they cannot be the result of serializing a
>> javascript object. It specifically defines a JSON *text*, so model
>> equivalence isn't sufficient.
>> Given that JPath is a subset of javascript access path syntax and
>> semantics, would a definition that references the appropriate ECMA clauses
>> meet with your approval? Or is this issue blocked IYO until a full JSON
>> transformation/mutation/update RFC is approved (whatever approval means).
>> Antony Blakey
>> -------------
>> CTO, Linkuistics Pty Ltd
>> Ph: 0438 840 787
>>
>> There are two ways of constructing a software design: One way is to make it
>> so simple that there are obviously no deficiencies, and the other way is to
>> make it so complicated that there are no obvious deficiencies.
>>  -- C. A. R. Hoare
>>
>>
>>
> 
> 

Mime
View raw message