You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jan Lehnardt (JIRA)" <ji...@apache.org> on 2009/01/23 21:45:59 UTC
[jira] Created: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Document a way to find out failed writes fro bulk requests and async writes
---------------------------------------------------------------------------
Key: COUCHDB-223
URL: https://issues.apache.org/jira/browse/COUCHDB-223
Project: CouchDB
Issue Type: Improvement
Components: Documentation
Reporter: Jan Lehnardt
Fix For: 0.9
A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "Damien Katz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682420#action_12682420 ]
Damien Katz commented on COUCHDB-223:
-------------------------------------
Now with bulk updates, failures in the bulk update are allowed or all or nothing, and each failure is returned. See the bulk docs test for more info.
We still need to document the api and how this works in the wiki.
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "David Van Couvering (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682200#action_12682200 ]
David Van Couvering commented on COUCHDB-223:
---------------------------------------------
As an attempt to help contribute to the 0.9 release, I'd be happy to document this if I understood better what the issue was. The description is a bit cryptic. Is there an email thread that discusses this further?
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "Chris Anderson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Anderson closed COUCHDB-223.
----------------------------------
Resolution: Fixed
David,
Thanks for documenting this. I think the appropriate place would be http://wiki.apache.org/couchdb/HTTP_Document_API section "Modify Multiple Documents With a Single Request"
The only thing I'd add to your above discussion is to call the non-all_or_nothing behavior the "default" so that people realize that they should expect that behavior.
If you don't feel like closing the loop on the wiki, please make a note here so someone else can pick it up. I'm closing the ticket now because I think we have the relevant information for documenting it, its just a matter of getting that info to the users.
Thanks!
Chris
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Lehnardt updated COUCHDB-223:
---------------------------------
Priority: Blocker (was: Major)
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682250#action_12682250 ]
Jan Lehnardt commented on COUCHDB-223:
--------------------------------------
Hi Dave, thanks. This is a note to document the new bulk_docs behaviour:
Details can be found here http://mail-archives.apache.org/mod_mbox/couchdb-dev/200902.mbox/%3c84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com%3e and the tests for the final API are here http://svn.apache.org/viewvc/couchdb/trunk/share/www/script/test/bulk_docs.js?view=markup
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682638#action_12682638 ]
Jan Lehnardt commented on COUCHDB-223:
--------------------------------------
Hi Dan, I think assignments can only go to committers. I don't know why, but I think we've got to live with it now. With your latest comment here, I think you safely claimed this issue :) Thanks for your help!
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "David Van Couvering (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683321#action_12683321 ]
David Van Couvering commented on COUCHDB-223:
---------------------------------------------
That's odd. In Apache Derby, anybody who went through a quick signup process could own issues, even if they weren't contributors.
Anyway, I was looking at doing a first draft of this, but couldn't really figure out where to put it in the Wiki. Perhaps it could go into howto, but is there somewhere I'm missing that already talks about bulk_docs functionality where I could just append/update the information?
Thanks!
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "David Van Couvering (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682559#action_12682559 ]
David Van Couvering commented on COUCHDB-223:
---------------------------------------------
I'd assign myself this issue but it says I don't have permission to work on it. I scanned the CouchDB pages, I can't find anything obvious about how to get permission. Can someone give me permission?
Thanks...
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-223) Document a way to find out failed
writes fro bulk requests and async writes
Posted by "David Van Couvering (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683328#action_12683328 ]
David Van Couvering commented on COUCHDB-223:
---------------------------------------------
Here's the first draft of this. It is missing example code, but I thought you could review the overall description of the problem and new semantics while I'm poking around trying to figure out what the example code should look like. The tests are written in JavaScript, and I can pull that code for an example, but shouldn't I also describe what the underlying HTTP request should look like?
In previous releases of CouchDB, bulk updates were transactional - in particular, all requests in a bulk update failed if any request failed or was in conflict. There were a couple of problems with this approach:
- This doesn't actually work with replication. Replication doesn't provide the same transactional semantics, so downstream replicas won't see "all-or-nothing" transactional semantics. Instead, they will see documents in an inconsistent state until replication of all documents involved in the bulk update completes. With bidirectional replication it can get even worse, because you can get edit conflicts that must be fixed manually.
- If your database is partioned (aka "sharded"), different documents within the transaction could live on different nodes in the cluster, and these kinds of transactional semantics don't work unless you use heavy, non-scalable approaches like two-phase commit.
With release 0.9 of CouchDB, transactional semantics have been changed to make sure CouchDB works well in replicated and partitioned environments. There are now two transactional models supported:
QUESTION: how does the user control which transactional model is used?
- all-or-nothing - When using _bulk_docs to update a set of documents, either all the documents will commit successfully or none will. However, it does not do conflict checking the documents will be committed even if there are conflicts. Conflicting versions of the document will be saved. To use this approach, set the all_or_nothing flag when issuing a _bulk_docs request.
TODO: Provide example code here...
- non-atomic - In this mode, some documents may successfully be saved and some may not, and it is up to the application to check that all documents were successfully saved/updated.
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes and we should document the preferred way for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.