On Wed, Nov 27, 2013 at 12:46 PM, Robert Newson <[email protected]> wrote:
> What request would trigger this fold? What arguments would it take? > I'm not sure what's "painful" about the existing _bulk_docs read and > write API's, though exist primarily for bulk importing/exporting, most > database interactions are document or view level. > > A user request is enough to take it in consideration. > Since the word "transaction" was mentioned, it's worth remembering > that couchdb supports fully ACID transactions at the individual > document level (and, yes, that's not an oxymoron). This idea would not > (could not) change that. For example, any document updated during this > fold would stay updated, even if the fold failed before reaching the > end. > > by transaction I mean a way to interact on a doc vs the current value in the database while uploading it. Did you read the proposed syntax? > Is there value in a bulk version of update handlers, I guess? > The question is more, why not? > > As for "list function /update handler half baby", I have no idea what > it means... > > probably what is described... ie reusing the same system behind: reusing the mechanism of `send` . > > B. > > > On 27 November 2013 08:58, Benoit Chesneau <[email protected]> wrote: > > 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. > > > > > > > >> -- > >> ,,,^..^,,, > >> >
