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 13:43:13 GMT
On Wed, Nov 27, 2013 at 12:46 PM, Robert Newson <rnewson@apache.org> 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 <bchesneau@gmail.com> wrote:
> > 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