You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Adam Kocoloski (JIRA)" <ji...@apache.org> on 2011/02/01 15:14:28 UTC
[jira] Commented: (COUCHDB-462) track conflict count in db_info
(was built-in conflicts view)
[ https://issues.apache.org/jira/browse/COUCHDB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989212#comment-12989212 ]
Adam Kocoloski commented on COUCHDB-462:
----------------------------------------
Hi Bob, thanks. I see a couple of problems with the patch:
1) https://github.com/bdionne/couchdb/commit/31a5672#L2R337
It looks like you're incrementing when deleted=true, rather than false.
2) https://github.com/bdionne/couchdb/commit/31a5672#L2R331
I think you're double-counting by passing N + NextN to count_non_deleted/2.
More broadly, and in the context of COUCHDB-988, I'm wondering if many of these key tree operations could benefit from a refactoring that adds a generalized couch_key_tree:fold function. I believe Randall Leeds wrote such a thing at one point in time. I'm picturing a fold that supports short-circuiting, possibly using the {ok, _} and {stop, _} tagged tuples convention from couch_btree.
... Actually, digressing a bit further, I'm curious if anyone has ever considered the tradeoffs of different methods of short-circuiting. The tagged tuples are one approach, but it could also be implemented with erlang:throw/1. I'd expect that when short-circuiting is rare throwing an exception is the preferred approach because it creates less garbage along the way. I'm not sure what would be best when short-circuiting is routine (e.g. in the btree).
> track conflict count in db_info (was built-in conflicts view)
> -------------------------------------------------------------
>
> Key: COUCHDB-462
> URL: https://issues.apache.org/jira/browse/COUCHDB-462
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Reporter: Adam Kocoloski
> Fix For: 1.2
>
> Attachments: 462-jan-2.patch, COUCHDB-462-adam-updated.patch, COUCHDB-462-jan.patch, conflicts_in_db_info.diff, conflicts_in_db_info2.diff, conflicts_view.diff, whitespace.diff
>
>
> This patch adds a built-in _conflicts view indexed by document ID that looks like
> GET /dbname/_conflicts
> {"rows":[
> {"id":"foo", "rev":"1-1aa8851c9bb2777e11ba56e0bf768649", "conflicts":["1-bdc15320c0850d4ee90ff43d1d298d5d"]}
> ]}
> GET /dbname/_conflicts?deleted=true
> {"rows":[
> {"id":"bar", "rev":"5-dd31186f5aa11ebd47eb664fb342f1b1", "conflicts":["5-a0efbb1990c961a078dc5308d03b7044"], "deleted_conflicts":["3-bdc15320c0850d4ee90ff43d1d298d5d","2-cce334eeeb02d04870e37dac6d33198a"]},
> {"id":"baz", "rev":"2-eec205a9d413992850a6e32678485900", "deleted":true, "deleted_conflicts":["2-10009b36e28478b213e04e71c1e08beb"]}
> ]}
> As the HTTPd and view layers are a bit outside my specialty I figured I should ask for a Review before Commit.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira