couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Williams <space.ship.travel...@gmail.com>
Subject Re: "ddoc" protocol for query server?
Date Sat, 21 Jul 2012 16:33:09 GMT
Also, does the ["reset"] command reset all design documents?

On 22 July 2012 04:24, Samuel Williams <space.ship.traveller@gmail.com>wrote:

> Hi Alexander,
>
> Thanks for the details, that is really helpful.
>
> It might be good if documentation was updated.
>
> W.R.T. design documents, why isn't it used for view related functions,
> since it seems to include all the code for that purpose? Is it due to
> efficiency? Is design document the future of the query server structure?
>
> Kind regards,
> Samuel
>
> On 22 July 2012 03:52, Alexander Shorin <kxepal@gmail.com> wrote:
>
>> Hi Samuel.
>>
>> I'd attempt to update query server documentation, but it was stopped
>> at point "not readable" |:
>> About "ddoc" command: yes, currently it is in use for any design
>> functions except views. It work in two phases:
>> 1. It delivered copy of design document to query server with message
>> ["ddoc", "new", "<<ddoc-id>>", {<<ddoc-json-object>>}] to
let query
>> server cache it. For each ddoc changes in CouchDB his new version also
>> been sent to query server processes.
>> 2. It ask query server which function to run by message ["ddoc",
>> "<<ddoc-id>>", ["path", "to", "function"], [<<function arguments>>]].
>> First element of function path points to "what design function to
>> execute" (shows,lists,filters,updates etc.) which also called as "ddoc
>> cmd".
>>
>> The best documentation is the source code for now:
>> https://github.com/apache/couchdb/tree/master/share/server
>>
>> --
>> ,,,^..^,,,
>>
>>
>> On Sat, Jul 21, 2012 at 7:27 PM, Samuel Williams
>> <space.ship.traveller@gmail.com> wrote:
>> > Hi,
>> >
>> > I've been reviewing various query server implementations and some seem
>> to
>> > have a "ddoc" command. I'm wondering if this is still used in CouchDB
>> 1.2
>> > and if so, where is the documentation?
>> >
>> > If not, why not?
>> >
>> > Kind regards,
>> > Samuel
>>
>
>

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