couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <paul.joseph.da...@gmail.com>
Subject Re: Optionally including docs in view results
Date Tue, 05 Aug 2008 18:26:51 GMT
There was a similar idea posted on another thread that I really liked,
looked at implementing and got scared of because of the mentioned
replication stuff in bulk docs.

The basic idea was to be able to post something like the following to _bulk_docs

{
  "put": {doc1, doc2, doc3}
  "delete": {doc4, doc5}
  "get": {doc6}
}

(Originally there was a post section too, but there's been talk on how
that's kinda shaky, so not sure about it right now)

And then it'd return something like:

{
   "put": { [doc1._id, doc1._rev, ...]}
   "get": { doc6 }
}

(Obviously thats all horribly invalid JSON, but hopefully it gets the
point across)

The idea is that updates/deletes/gets are processed in probably that
order. So if you request a doc you just deleted, you'll get a delted
doc. And if you delete a doc you just updated, then you just wasted
everyone's time.

A thought that just occurred, would it help at all to rename
_bulk_docs to _transaction? That sounds a bit better to me. Also
sitting on the outside with no erlang fu, it seems kind of weird that
replication is using special additions to bulk_docs parameters. Unless
of course damien yells at me says those are just undocumented features
that might have other uses :D

And I'm spent.


On Tue, Aug 5, 2008 at 12:30 PM, Chris Anderson <jchris@grabb.it> wrote:
> On Tue, Aug 5, 2008 at 9:02 AM, Troy Kruthoff <tkruthoff@blit.com> wrote:
>> +1 for the bulk_docs api, specifically being able to perform multiple
>> REST-type operations in a single request should be "bulk_docs" by
>> definition.
>>
>
> Part of the complexity comes from the fact that _bulk_docs is already
> used in replication, so it has some options that aren't normally used
> in a standard POST from an application.
>
> Currently with _bulk_docs you can do the equivalent of PUT
> (create/update with _id), POST (create without _id), and DELETE
> (update set _deleted=true). So most of the RESTful options are
> available, they just aren't segregated by verb.
>
> You can't do GET yet - to me it just seems confusing to allow both
> modification of documents and fetching of documents in the same http
> request.
>
> If I'm wrong, and we really should include document fetches in
> _bulk_docs, it won't be impossible to code, but we should make sure
> the feature is clear.
>
> The POST body can certainly accommodate both "docs" and "ids" members,
> its just a matter of how to structure the response so that it's clear
> which parts of the response come from which CouchDB actions. (Not to
> mention all the edge-cases around documents that are both updated by
> the "docs" member, and requested by the "ids" member, or maybe the
> update phase succeeds but one of the request docs is 404.)
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

Mime
View raw message