On Sun, Dec 1, 2013 at 6:33 AM, Filippo Fadda <[email protected]> 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: https://jhs.iriscouch.com/files/debugger/debug.html >> 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. -- ,,,^..^,,
