couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: proposed feature - list function /update handler half baby
Date Wed, 27 Nov 2013 11:46:31 GMT
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.

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

Is there value in a bulk version of update handlers, I guess?

As for "list function /update handler half baby", I have no idea what
it means...


On 27 November 2013 08:58, Benoit Chesneau <> wrote:
> On Wed, Nov 27, 2013 at 9:46 AM, Alexander Shorin <> wrote:
>> On Wed, Nov 27, 2013 at 12:38 PM, Benoit Chesneau <>
>> wrote:
>> > On Wed, Nov 27, 2013 at 9:33 AM, Alexander Shorin <>
>> 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...
>> 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.
>> --
>> ,,,^..^,,,

View raw message