On Wed, Nov 27, 2013 at 9:46 AM, Alexander Shorin <[email protected]> wrote:
> On Wed, Nov 27, 2013 at 12:38 PM, Benoit Chesneau <[email protected]> > wrote: > > On Wed, Nov 27, 2013 at 9:33 AM, Alexander Shorin <[email protected]> > wrote: > > > >> mmm..this would require to be database admin and might not been > >> optimal. May be have just update function name there? Also, I believe, > >> such call will ignore any custom response from update function, right? > >> -- > >> ,,,^..^,,, > >> > >> > > The purpose would be to only handle the updates of a docs coming in a > blik > > update. The return message won't change, > > > > For the admin rights, I don't see, all the rights working for a bulk > update > > will be applied there. > > Due to custom source code execution like in case of temp views. While > it's might be ok for sandboxed languages, I don't like to have such > feature for Python query server or even Erlang one for oblivious > reasons(: > Well let the operator decides. Want sandboxed execution, run couchdb or the view script in a protected process. either using a vm, seccomp, limits... Other than that you konw what could happen when doing that. Not every people are using a couch exposed to the public. Only to the applications. And it's not more dangerous than running a script in the view engine. either temp views or normal views. > > > Note that such function could introduce the possibility to have > > transactions. Imagine you could also access to the database api in such > > function... > > Hm..to have real transaction feature you need to operate with all > posted documents e.g. this would be not update function, but something > different with signature (docs, req) // note docs instead of doc > Yes eventually such functions should have a req, and then we pass doc after doc like for the views. That would be better anyway. The response may be adapated I agree. But it would be returned by couchdb not by the function. This function would only return docs. > > For access to the database api inside design functions I'm not > sure...I'm playing within for lua query server - it's cool and > very-very powerful feature, but it works just because I could pass > native Erlang couch_* functions into it. For other languages I fear we > have to setup some generic RPC service on CouchDB side for that (and > make a lot of work for public API) and not sure that this is wise > idea. > > You can pass any call using STDIO too. we "just" need to make the protocol a little more asynchronous, passing messages to the erlang side. What we are doing with lists. It will be a little faster using a "native" language but that's all. Anyway these are implementations details. I reallly think that such idea could be very powerful. > -- > ,,,^..^,,, >
