couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: partial/diff updates?
Date Thu, 27 Nov 2008 18:12:31 GMT

On 27 Nov 2008, at 09:53, Burobjorn wrote:

> I like this approach.
>
> This also creates the possibility to benchmark and compare the diff
> methodology versus a full update.

The problem is that this would be a synthetic benchmark. I'd still  
very much like to
see a real world application that shows in numbers that it needs  
partial updates.
Until then it is just premature optimization. A neat feature for sure,  
but needed,
nobody knows.

Jan
--


> 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