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" <[email protected]> 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" <[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(: >> >> > 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. >> >> -- >> ,,,^..^,,, >> >
