couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [jira] [Created] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
Date Thu, 06 Oct 2011 04:53:20 GMT
On Thursday, October 6, 2011, Benjamin Young (Commented) (JIRA) <> wrote:
>    []
> Benjamin Young commented on COUCHDB-1303:
> -----------------------------------------
> Others have hit this situation as well:
>> Add a _bulk_update handler similar to _update but for bulk document
>>                 Key: COUCHDB-1303
>>                 URL:
>>             Project: CouchDB
>>          Issue Type: New Feature
>>            Reporter: Benjamin Young
>>              Labels: api, update_request_handler
>> _update handlers are great (and getting better!) for building RESTful
API's inside CouchDB. One limitation I found tonight is that _update can
only do a single document at a time. If the API I'm building needs to update
multiple docs (in a similar fashion to _bulk_docs), then an outside "proxy"
script is required. It would be ideal to have a _bulk_update handler to
allow for the same functionality as _update, but with the ability to insert
multiple documents at once.
>> Perhaps the current _update handler API could be extended to support
multiple IDs/documents, but a separate API endpoint would be seem reasonable
if needed.
>> Thanks for considering this idea.
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> For more information on JIRA, see:

I would really prefer to sit down a little and start to rethink the couchapp
engine. Restful means imo  that on a particular resource we could react on
each actions (here HTTP verbs). Instead we did the same error Rails did by
having a resource per actions or so. Bulk updates would be another hack
around this so I'm -1 on such features. New ticket about what i would like
to design is coming along.

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