Filippo, I heard you, thanks.
And FYI show, list and other functions are already "plugins": you may disable them at httpd_design_handlers config section in any time or replace them by your own implementation. -- ,,,^..^,,, On Sun, Dec 1, 2013 at 7:28 PM, Filippo Fadda <[email protected]> wrote: > > On Dec 1, 2013, at 4:26 AM, Alexander Shorin wrote: >> You can do the same with Erlang query server since it has access to >> all internal functions. > > I can do it in PHP inside my Query Server (I already said this to you), > without the need to investigate the CouchDB internals, trying to find the > functions to do that. I can simply include ElephantOnCouch inside my query > server and use it. But I'm not gonna do that, because I can obtain the same > result with a simple PHP script. > Should I use ErLang, learning something that is not documented, spending > days, just to obtain a little performance gain? Who cares! > You know why Oracle invented PL/SQL, Microsoft created Transact SQL or any > other RDBMS uses an SQL dialect? BECAUSE THEY ARE SIMPLE! > The internal functions you are talking about are not even documented for > christ's sake. > >> 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. > > The main purpose of a stored procedure is to elaborate data. The results are > new data or data changes. You can't do that inside a list or a show, so they > are not stored procedures. The only way you can do that is using ErLang, > right? Wow, this is great, same as writing an Oracle stored procedure using C > and the Oracle undocumented "internal functions". I'm sarcastic. > There is no point using list and show, unless you are writing a CouchApp > using CouchDB as an application server. Full stop. For me CouchDB is a > database, not an application server. Things like show and list shouldn't be > part of the core. > >> 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 > > I'm not gonna complicate my life when I can use any IDE with xdebug, unit > testing, step by step debugging. > >> 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. > > And since I'm not interested in a CouchApp and I think CouchDB should be a > database - not an application server - I don't think the concept should be > part of CouchDB. This is MY opinion. You have a different vision of what > CouchDB should be, an application server, we already know that. Why do you > insist so much? > >> 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?(: > > I don't use them and I don't want them inside CouchDB because those > functional requirements (list and show) don't fit the goals of the product, > since the product, for me, it's a database and not an application server. > It's pretty clear, why can't you understand? > PHP is a different, it's not a database, it's a language with a standard > library and a ton of extensions. > List and show could be made available as a CouchDB plugin. This plugin can be > called CouchApp. This is my vision. And this my last word on the subject. > > -Filippo
