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.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
