couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ari Najarian (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
Date Mon, 09 Dec 2013 16:30:08 GMT


Ari Najarian commented on COUCHDB-1303:

Thanks, all, for revisiting this discussion.

Just so I'm clear, what Benjamin is proposing (the wrapper for _bulk_docs) would still require
some kind of middleware in order to 'prepare' the list of documents to send, correct? I'd
likely have to get client-side JS / Node / Lasso / PHP / whatever to query ddoc/_view/viewname?include_docs=true,
grab those results, and pipe them into this update wrapper.

Is there a design reason why piping a view directly into the wrapper wouldn't work? If it's
technically feasible, this would cut down on the round-trips to the server (and latency, and
bandwidth usage, and overall throughput between CouchDB and the client). It also means less
code in less places for developers (like me!).

> Add a _bulk_update handler similar to _update but for bulk document changes
> ---------------------------------------------------------------------------
>                 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 was sent by Atlassian JIRA

View raw message