2009/1/26 Jan Lehnardt <[email protected]>: > > On 24 Jan 2009, at 21:37, Matt Goodall wrote: > >> 2009/1/24 Matt Goodall <[email protected]>: >>> >>> Hi, >>> >>> I'm a bit confused why this was closed. Perhaps a description of the >>> "new behaviour" is available somewhere? >>> >>> The only mention of anything related to a change in _bulk_docs I've >>> *noticed* is about not failing everything in the list of updates >>> (might be nice if that was optional, actually) and the associated >>> error reporting. However, that doesn't necessarily fix the problem I >>> described. >> >> Actually, I think I misunderstood the change. It seems it's only to >> say what document failed, i.e. better error reporting, in which case, >> a) the change sounds good, b) there is nothing to make optional, c) I >> still don't think it addresses the issue. Please correct me if I'm >> wrong! > > We can't sensibly make bulk requests with database partitioning > over multiple nodes. Damien talked about changing the bulk request > behaviour also for single-nodes to avoid confusion. If I understand > correctly, bulk writes then work a lot like replication, in that your > data gets written in any case but might cause conflicts and you > can find out where conflicts occurred using a view checking > the `_conflicts` member of a doc.
That sounds like a _bulk_update is going to remain an atomic operation but no longer make any promises about consistency, even on a single node. Is that a correct summary? If so, I think the wiki page, http://wiki.apache.org/couchdb/HTTP_Document_API, should be updated asap to avoid confusion. Regardless of whether _bulk_update changes, I'm still not convinced the ticket should be closed. Deleting a document and then adding a document with the same id works for multiple HTTP request and replication, it should work for _bulk_update too. - Matt > > >>> Can anyone explain how the planned change fixes things? >>> >>> Thanks, Matt >>> >>> 2009/1/24 Jan Lehnardt (JIRA) <[email protected]>: >>>> >>>> [ >>>> https://issues.apache.org/jira/browse/COUCHDB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>> ] >>>> >>>> Jan Lehnardt closed COUCHDB-188. >>>> -------------------------------- >>>> >>>> Resolution: Invalid >>>> Fix Version/s: 0.9 >>>> >>>> bulk update will get a new behaviour in 0.9. Closing >>>> >>>>> _bulk_docs fails when deleting and adding a doc with the same id >>>>> ---------------------------------------------------------------- >>>>> >>>>> Key: COUCHDB-188 >>>>> URL: https://issues.apache.org/jira/browse/COUCHDB-188 >>>>> Project: CouchDB >>>>> Issue Type: Bug >>>>> Components: Database Core >>>>> Affects Versions: 0.9 >>>>> Environment: CouchDB revision 730414. >>>>> Reporter: Matt Goodall >>>>> Fix For: 0.9 >>>>> >>>>> >>>>> CouchDB returns a "412 Precondition Failed" when the list of changes >>>>> sent to _bulk_docs deletes a document and later creates a document with >>>>> the >>>>> same id as the deleted document: >>>>> {"docs": [ >>>>> {"_id": "docid", "_rev": "<rev>", "_deleted": true}, >>>>> {"_id": "docid"} >>>>> ]} >>>>> Once fixed, the response JSON document will return the same docid >>>>> twice in the list but it's presumably ordered consistently with the >>>>> request >>>>> data so any client should be able to understand the response. >>>>> Demonstrating the problem using curl is easy enough: >>>>> $ curl -X PUT http://localhost:5984/test >>>>> {"ok":true} >>>>> $ curl -X PUT -d "{}" http://localhost:5984/test/docid >>>>> {"ok":true,"id":"docid","rev":"4140747751"} >>>>> $ curl -X POST -d '{"docs": [{"_id": "docid", "_rev": "4140747751", >>>>> "_deleted": true}, {"_id": "docid"}]}' >>>>> http://localhost:5984/test/_bulk_docs >>>>> {"error":"conflict","reason":"Document update conflict."} >>>>> Note: this is likely related to COUCHDB-172.
