incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Iriele <siriele...@gmail.com>
Subject Re: proposed feature - list function /update handler half baby
Date Wed, 27 Nov 2013 08:57:50 GMT
I guess my point is I would like a feature that let's me do bulk updates
without loading them all out And putting them all back... That's as
intuitive as the other hosts of functions... If I got the green light I'd
be happy to pitch in in the code base... Maybe as an experimental feature
or something
On Nov 27, 2013 12:55 AM, "Stanley Iriele" <siriele2x3@gmail.com> wrote:

> @florian I am not sure what you mean 1 doc update changes all others...I
> basically you operate on an index of things... Just like a list applies to
> a view... And each call flushes a doc... Its OK for bulk updates to take a
> while....
>
> And the output would be what is returned from the bulk updates right
> now...which is an array of doc ids...and revs... And it can have the same
> basic config... Or you could pass in "keys" and you work with that...
> Basically the building blocks for doing it are there... And bulk updates in
> couch db are painful... And I usually avoid it like the plague
> On Nov 27, 2013 12: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(:
>>
>> > 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
>>
>> 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.
>>
>> --
>> ,,,^..^,,,
>>
>

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