couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timo Isokoski" <timo.isoko...@gmail.com>
Subject Re: partial/diff updates?
Date Thu, 27 Nov 2008 16:59:16 GMT
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
>
>
>


-- 
Timo Isokoski
+358503054649

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