couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: [discuss] down, spammed
Date Sun, 01 Dec 2013 03:26:06 GMT
On Sun, Dec 1, 2013 at 6:33 AM, Filippo Fadda
<> wrote:
> On Dec 1, 2013, at 1:18 AM, Benoit Chesneau wrote:
>> And you keep ignoring what I said about the doc. Ie. it is not complete
>> (and it must be fixed).
>> Like stored procedure they are stored. Like  stored procedure they can be
>> used in a query. Afaik queries happen on HTTP level in couchdb.
>> Also "are side effect free and idempotent" = no side effect and idempotent
> You can manipulate data inside a stored procedure, you can change values, entire rows,
delete columns, change a column type, you can do whatever you want, even drop a table. A stored
procedure can have side effects, obviously. And you can debug your code.

You can do the same with Erlang query server since it has access to
all internal functions. But I don't think you'd like to shot youself
in foot by such side effects by losing all your data (; I even wonder
if you really wanted them since it's good practice to have no global
state and no side effects for any functions no matter where they are
been executed: on CouchDB or inside your program. No state and no side
effects guarantees you portability and explicit behaviour. For more
arguments follow the functional programming languages - this is quite
interesting world, but this is offtopic.

Also, ability to debug code is mostly depends on query server - the
standalone process that executes design functions. To debug Erlang
function you may use Erlang features (I couldn't recommend any since
I'm currently follow debug-by-logs way); for Python I made mock query
server and quite rich set of utilities to test you code right in your
IDE without uploading it to CouchDB; for JavaScript you may even debug
inside your browser:

>> You're just ignoring how to use shows and lists and how they are used. Some
>> are just using them like a way to handle and merge different sets using
>> links and joins. And like many things in couchdb they need to be improved
>> in term of performance.
> I'm not ignoring anything Benoit, believe me.
>> Moving on what exactly? You keep saying we should remove the couchapp
>> engine etc.... But the why is still unclear. To be honest it's hard to
>> discuss about such topic without knowing what's your business with couchdb.
>> Maybe you could clarify that?
> For me CouchDB is a database and I use it like a database, storing and retrieving documents,
that's all. I don't need an application server and I don't need couch apps. I like the idea
of stored procedures but I don't find them so important, and like they are, list and show,
are useless to me. They are pretty hard to debug and I don't see any use case for them. I
can do the same with a PHP script.

The idea of CouchApp not only to write some own code in
JS/PHP/Python/etc. but also to be able share them with easy using
replication feature. People are able to just replicate your app to own
local host (even to mobile futon) and they shouldn't it broken. The
rough edge are custom query servers, but it isn't an big issue: I'd
run Python query server on Android with easy, same should be for other
langs, I'm sure.

Outside of CouchApp context, the main goal of show and list functions
to format doc and view responses in the way you need: return them as
nice HTML page or preprocess data before clients will get them or
something else. This is a feature: you may use it, you may don't.
Really, you don't argue for removal every PHP std function that you
found useless, right?(:

For debugging see above - it's all depends on query server
implementation, CouchDB doesn't controls things inside query servers
and even doesn't cares about them much: just respect the protocol and
send response before time is out.


View raw message