incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Kocoloski (JIRA)" <>
Subject [jira] Commented: (COUCHDB-462) track conflict count in db_info (was built-in conflicts view)
Date Tue, 01 Feb 2011 14:14:28 GMT


Adam Kocoloski commented on COUCHDB-462:

Hi Bob, thanks.  I see a couple of problems with the patch:


It looks like you're incrementing when deleted=true, rather than false.


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:
>             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"],
> {"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:


View raw message