couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ari Najarian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
Date Sun, 08 Dec 2013 03:24:35 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842387#comment-13842387
] 

Ari Najarian commented on COUCHDB-1303:
---------------------------------------

So... it's been 2 years since the last comment on this thread, but I thought I'd throw my
2 cents in. I know this is much more complex an undertaking than I can imagine, but I would
find this functionality extremely useful were it implemented. As far as the REST API is concerned,
this is what I envision: since bulk methods already take an array of documents (that currently
have to be specified), why not 'pipe' in the results of a view (with the same standard query
parameters to select different portions), and just include an additional parameter to specify
the design document / update handler to use on the operation?

Say you want to 'reassign' a bunch of documents from one parent doc to another (e.g. tasks
on a project, new manager for a bunch of staff, etc.). The bulk update API call could look
something like this:

{noformat}/db/bulk_update?mode=view&source=ddoc/_view/tasks&handler=ddoc/_update/reassign_project&startkey=['task_id']&endkey=['task_id',{}]&new_project_id=1234{noformat}

or

{noformat}/db/bulk_update?mode=view&source=ddoc/_view/staff&handler=ddoc/_update/reassign_manager&startkey=['old_manager_id']&endkey=['old_manager_id',{}]&new_manager_id=1234{noformat}

The {{mode}} param could be 'view' or 'docs' - in the case of the former, you provide the
view name via {{source}}. In the case of the latter, you provide the documents as JSON in
the request body. Standard view query parameters ({{startkey, endkey, keys}}, etc.) could
be used with {{mode=view}}, and any additional params in the request would simply get passed
into the update handler, where they could be retrieved in {{req.form}} or {{req.query}}.

While not the prettiest implementation (and could definitely use some refinement), all the
pieces are there to source a document array from an existing view, and a handler from an existing
design document.

The real beauty of bulk update handlers implemented this way can be illustrated in the following
scenario: say that you're using email addresses as unique IDs for all staff in your system.
Some staff are managers, others are employees. Employees have a 'manager' key whose value
is the email address of the manager, so you can group them all by manager by using a complex
key on a view index. One manager changes their email address IRL. So we PUT to:

{{db/_design/ddoc/_update/change_email/employee_id?new=new@email.com}}

The change_email update handler looks like this (!!):

{code:javascript}
function(doc,req){
  var old = doc.email;
  doc.email = req.query.new;
  if(doc.manager){
    response = {
      code: 302,
      headers: {
        "Location" : "/" + req.info.db_name + "/bulk_update?mode=view&source=ddoc/_view/staff&handler=ddoc/_update/reassign_manager&startkey=['"
+ old + "']&endkey=['" + old + "',{}]&new_manager_id=" + doc.email,
        "Content-Type" : "application/json"
      },
      body: ""
    }
    return[doc,response];
  }
  else{
    return[doc,"Email has been updated"];
  }
}
{code}

So, we update one record using a single update handler, and then conditionally redirect to
the _bulk_update handler to update all the "related" documents in the database! Any time a
manager changes their email address, we no longer have to worry about updating all the other
docs using middleware. This would be so awesome.

I've come to rely very heavily on CouchApps, and the more I can do without leaving the stack,
the happier / more productive / more effective I am. Bulk update handlers would fill a huge
gap in my projects, by getting the server to do more heavy lifting, instead of relying on
the client to do everything.

I hope the possibilities I outlined above excite you guys as much as they excite me. Perhaps
we can revisit bulk update handlers in an upcoming version?

> Add a _bulk_update handler similar to _update but for bulk document changes
> ---------------------------------------------------------------------------
>
>                 Key: COUCHDB-1303
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1303
>             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
(v6.1#6144)

Mime
View raw message