"ddoc" protocol for query server?

[Samuel Williams <sp...@gmail.com>]

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

Re: "ddoc" protocol for query server?

[Alexander Shorin <kx...@gmail.com>]

On Sat, Jul 21, 2012 at 8:24 PM, Samuel Williams
<sp...@gmail.com> wrote:
>
> 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?

For backward compatibility: even modern query server still able to
serve for 0.8+ CouchDB there was only map/reduce functions. Other
design functions was introduced only in 0.9 release with stand alone
commands and at 0.11 they was refactored to be as subcommand for
"ddoc". However, that's my own opinion why so - probably actual
developers are able to give you more correct answer.

To track all query server history, you may take a look at Python
one[1] - there was implemented support for all CouchDB versions within
single server and all their differences are well described.

[1] https://code.google.com/r/kxepal-couchdb-python-featured/source/browse/couchdb/server/__init__.py?name=viewserver#303

--
,,,^..^,,,

Re: "ddoc" protocol for query server?

[Samuel Williams <sp...@gmail.com>]

Thanks for your help.

On 22 July 2012 04:55, Alexander Shorin <kx...@gmail.com> wrote:

> > 1/ Does modern 1.2 server use the old map/reduce functions at all?
> Yes. There wasn't serious changes for all time except addition of
> shared library for map functions
>
> > 2/ I noticed that errors in some cases seem to be returned as an array
> (old
> > way?) but in the docs it gives an example using a hash, so I'm assuming
> > this is the modern way?
>
> No: array format is modern one. Errors format of errors was changed in
> 0.11 from:
> {"error": "<<error>>", "reason": "<<reason>>"}
> to
> ["error", "<<error>>", "<<reason>>"]
> However, the "forbidden" error leaved without any changes:
> {"forbidden": "<<reason>>"}
>
> --
> ,,,^..^,,,
>
>
> On Sat, Jul 21, 2012 at 8:48 PM, Samuel Williams
> <sp...@gmail.com> wrote:
> > 1/ Does modern 1.2 server use the old map/reduce functions at all?
> >
> > 2/ I noticed that errors in some cases seem to be returned as an array
> (old
> > way?) but in the docs it gives an example using a hash, so I'm assuming
> > this is the modern way?
> >
> > On 22 July 2012 04:36, Alexander Shorin <kx...@gmail.com> wrote:
> >
> >> On Sat, Jul 21, 2012 at 8:33 PM, Samuel Williams
> >> <sp...@gmail.com> wrote:
> >> > Also, does the ["reset"] command reset all design documents?
> >>
> >> No. It only drops cached map functions and query server configuration
> >> that handled reduce overflow option.
> >>
> >> --
> >> ,,,^..^,,,
> >>
>

Re: "ddoc" protocol for query server?

[Alexander Shorin <kx...@gmail.com>]

> 1/ Does modern 1.2 server use the old map/reduce functions at all?
Yes. There wasn't serious changes for all time except addition of
shared library for map functions

> 2/ I noticed that errors in some cases seem to be returned as an array (old
> way?) but in the docs it gives an example using a hash, so I'm assuming
> this is the modern way?

No: array format is modern one. Errors format of errors was changed in
0.11 from:
{"error": "<<error>>", "reason": "<<reason>>"}
to
["error", "<<error>>", "<<reason>>"]
However, the "forbidden" error leaved without any changes:
{"forbidden": "<<reason>>"}

--
,,,^..^,,,


On Sat, Jul 21, 2012 at 8:48 PM, Samuel Williams
<sp...@gmail.com> wrote:
> 1/ Does modern 1.2 server use the old map/reduce functions at all?
>
> 2/ I noticed that errors in some cases seem to be returned as an array (old
> way?) but in the docs it gives an example using a hash, so I'm assuming
> this is the modern way?
>
> On 22 July 2012 04:36, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Sat, Jul 21, 2012 at 8:33 PM, Samuel Williams
>> <sp...@gmail.com> wrote:
>> > Also, does the ["reset"] command reset all design documents?
>>
>> No. It only drops cached map functions and query server configuration
>> that handled reduce overflow option.
>>
>> --
>> ,,,^..^,,,
>>

Re: "ddoc" protocol for query server?

[Samuel Williams <sp...@gmail.com>]

1/ Does modern 1.2 server use the old map/reduce functions at all?

2/ I noticed that errors in some cases seem to be returned as an array (old
way?) but in the docs it gives an example using a hash, so I'm assuming
this is the modern way?

On 22 July 2012 04:36, Alexander Shorin <kx...@gmail.com> wrote:

> On Sat, Jul 21, 2012 at 8:33 PM, Samuel Williams
> <sp...@gmail.com> wrote:
> > Also, does the ["reset"] command reset all design documents?
>
> No. It only drops cached map functions and query server configuration
> that handled reduce overflow option.
>
> --
> ,,,^..^,,,
>

Re: "ddoc" protocol for query server?

[Alexander Shorin <kx...@gmail.com>]

On Sat, Jul 21, 2012 at 8:33 PM, Samuel Williams
<sp...@gmail.com> wrote:
> Also, does the ["reset"] command reset all design documents?

No. It only drops cached map functions and query server configuration
that handled reduce overflow option.

--
,,,^..^,,,

Re: "ddoc" protocol for query server?

[Samuel Williams <sp...@gmail.com>]

Also, does the ["reset"] command reset all design documents?

On 22 July 2012 04:24, Samuel Williams <sp...@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 <kx...@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
>> <sp...@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
>>
>
>

Re: "ddoc" protocol for query server?

[Samuel Williams <sp...@gmail.com>]

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 <kx...@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
> <sp...@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
>

Re: "ddoc" protocol for query server?

[Alexander Shorin <kx...@gmail.com>]

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
<sp...@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