On Mon, Aug 3, 2009 at 11:51 AM, Brian Candler<[email protected]> wrote: > On Mon, Aug 03, 2009 at 01:10:42PM +0200, Jan Lehnardt wrote: >> >> On 3 Aug 2009, at 11:04, Brian Candler wrote: >> >>> Is there any reason why, if you POST a document to a database and that >>> document has an "_id" member, why this is ignored and a server- >>> generated _id >>> is used instead? >>> >>> $ curl -X PUT http://127.0.0.1:5984/sample >>> {"ok":true} >>> $ curl --data-binary '{"_id":"foo","bar":"baz"}' -X POST >>> http://127.0.0.1:5984/sample >>> {"ok >>> ":true,"id":"f38341efa1ca9bebc528b452aa036846","rev":"1-4165745669"} >> >> The API for creating a named document is PUT /db/docid >> POSTing to /db is "add to a collection and let the server >> care about identity." >> >> >>> This seems inconsisent with a POST to _bulk_docs >>> >>> $ curl --data-binary '{"docs":[{"_id":"foo","bar":"baz"}]}' -X POST >>> http://127.0.0.1:5984/sample/_bulk_docs >>> [{"id":"foo","rev":"1-1298018621"}] >> >> Bulk docs is different API. >> >> -- >> >> That's the reasons. Do you propose a change? :) > > Well, I was just a bit surprised when I had prepared an off-line design > document like this: > > { > "_id":"_design/whatever", > "views":{...} > } > > and I thought I'd just POST it to the database, and found I got a random ID. > > FWIW, the _bulk_docs API lets you do both: if you include an _id then it is > used; if you don't then you get a random one. > > So I'd say it would be more consistent if POST to database would do the > same. Then it's one less API rule to remember. > > Regards, > > Brian. >
I had a recent conversation with someone about this for something or other. It can be a bit surprising, but as Jan points out the current intent is based on the verb and URL that's used. Another thing to check is what happens if you POST with a _rev attribute. Does it get discarded, or would it trigger a conflict? Either way, perhaps we should poll the community and see what the general consensus would be for respecting an _id or _rev in the POST body? Paul
