You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Brian Smith <br...@briansmith.org> on 2008/04/14 22:27:18 UTC

RE: PUT / POST tradeoffs

Chris Anderson wrote:
> The alternative approach is to forgo the MD5 hash calculation, and
> POST the parsed data into CouchDB, creating a new record with an
> arbitrary id. I imagine that I would end up with a lot of identical
> data in this case, and it would become the job of the
> Map/Combine/Reduce process to filter duplicates while creating the
> lookup indexes.

PUT is almost always better than POST; if you experience network
failures, you can retry the PUT without any ill effects. If you use
POST, and your experience a network partition before you get the
response, how will you determine whether or not the POST succeeded? See
"Post Once Exactly" (http://www.mnot.net/blog/2005/03/21/poe), HTTPLR
(http://dehora.net/doc/httplr/draft-httplr-01.html), and their related
discussions.

- Brian


Re: PUT / POST tradeoffs

Posted by Chris Anderson <jc...@mfdz.com>.
On Mon, Apr 14, 2008 at 1:27 PM, Brian Smith <br...@briansmith.org> wrote:
>
>  PUT is almost always better than POST; if you experience network
>  failures, you can retry the PUT without any ill effects. If you use
>  POST, and your experience a network partition before you get the
>  response, how will you determine whether or not the POST succeeded? See
>  "Post Once Exactly" (http://www.mnot.net/blog/2005/03/21/poe), HTTPLR
>  (http://dehora.net/doc/httplr/draft-httplr-01.html), and their related
>  discussions.

Thanks Brian - I think I meant PUT... I've been using the batch POST
(which acts like PUT if you specify the document_id) so I spoke a
little fuzzily. And that's an extremely clear rational for PUT.

Chris

-- 
Chris Anderson
http://jchris.mfdz.com