On Sat, Jun 12, 2010 at 23:18, Jason Smith <jhs@couch.io> wrote:
On Sat, Jun 12, 2010 at 23:13, Paul Bonser <misterpib@gmail.com> wrote:
> Why not have these three cases:
>
>  * Document update: doc is something, req.id == doc._id
>  * Document create, PUT to _update/some_id: doc is null, req.id is "some_id"
>  * Document create, POST to _update, doc is null, req.is is a random uuid
>
> The update function can decide whether or not to honor the "suggested" doc
> id but at least it is now capable of matching the JSON API.

Ah yes, making it a bit closer to the way that a regular PUT vs. POST
works. What if someone POSTs an ID as part of the _update request?
Return an error telling them that they can only include a doc ID as
part of a PUT?

Wow, when you do it this way, it is just a 1-line patch (attached).

The update function can now do

    if(doc && doc._id == req.id)
      // To be pedantic, I could confirm req.method == "PUT"
      log("I am an update by id");
    else if(doc === null && req.id) {
      if(req.method == "POST")
        log("I am a create, id was auto-generated");
      else if(req.method == "PUT")
        log("I am a create, id was supplied by client");
    }

Thoughts? Does this count as an API change? Even if so, I feel like it fixes a bug.

Well, my objective is that it is *possible* for _update to match the JSON API.

Users can POST to _update/some_id with a JSON whose _id doesn't match. A well-written update function would presumably return an error (or whatever straight couch does).


>
> --
> Jason Smith
> Couchio Hosting
>



--
Paul Bonser
http://probablyprogramming.com



--
Jason Smith
Couchio Hosting



--
Jason Smith
Couchio Hosting