incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: proposed feature - list function /update handler half baby
Date Wed, 27 Nov 2013 08:58:44 GMT
On Wed, Nov 27, 2013 at 9:46 AM, Alexander Shorin <kxepal@gmail.com> wrote:

> On Wed, Nov 27, 2013 at 12:38 PM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> > On Wed, Nov 27, 2013 at 9:33 AM, Alexander Shorin <kxepal@gmail.com>
> 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.



> --
> ,,,^..^,,,
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message