couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klaus Trainer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-902) Attachments that have recovered from conflict do not accept attachments.
Date Sat, 08 Jan 2011 23:36:45 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979231#action_12979231
] 

Klaus Trainer commented on COUCHDB-902:
---------------------------------------

Adam Kocoloski wrote:
> Can you add an etap test for couch_key_tree showing a spurious conflict when the incoming
path has more than 2 entries? 

Yeah, I'll do that. The tests in the attached patch will detect spurious conflicts. However
it's probably not the worst idea to write an additional etap test for the couch_key_tree module
only.


Paul Joseph Davis wrote:
> Can someone remind me why we have the full revision history only for attachments in the
first place? Unless I'm crazy, that seems like its the actual bug. 

As opposed to Adam's speculation, there _is_ an actual reason for that.

When updating a document body, the new document body is supplied by the client. The new #doc{}
that is passed to couch_doc:to_path/1 consists of the new document body supplied by the client
and the revs tree containing the current, if available, and the new rev. Therefore, the resulting
path contains at most two revs.

In contrast, when updating with an attachment, the new document body is equal to the current
one, and therefore isn't supplied by the client. That's the reason why couch_db:open_doc_revs/4
is called in couch_httpd_db:db_attachment_req/4. As the #doc{} that is returned by the function
call contains the full revs tree, the #doc{} that's passed to couch_doc:to_path/1 does as
well.


Let me propose another (probably nicer) solution.

We could introduce another function couch_key_tree:merge/4. The fourth argument would be a
flag telling whether merge conflicts are allowed or not.

merge/4 would call merge/3. When calling merge/4, the only difference from directly calling
merge/3 would be that if the `MergeConflicts` flag is false, the revs tree is pruned.

What do you think about that?

> Attachments that have recovered from conflict do not accept attachments.
> ------------------------------------------------------------------------
>
>                 Key: COUCHDB-902
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-902
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>         Environment: trunk
>            Reporter: Paul Joseph Davis
>            Priority: Critical
>         Attachments: 0001-Fix-COUCHDB-902.patch, couchdb-902-test-case.py
>
>
> Apparently if a document has been in a conflict, they will reject requests to add an
attachment with a conflict error.
> I've tracked this down to couch_db_updater.erl line 501, but I'm not too familiar with
this part of the code so I figured I'd fill out a ticket in case anyone else can go through
this more quickly than me.
> Sure would be nice if I could attach a file when I create an issue...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message