Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CA+pq5fq7i8bXr9fv0dZYQPOEU3_0x=D1OcgwS3qqio=_mpYoEg@mail.gmail.com>
References: 
 <CAJ1bcfH1vvXiAsEp6_nc5F5a0hL3+n=DoJj-mct_EP6Q_Qzijg@mail.gmail.com>
	<CA+pq5fq7i8bXr9fv0dZYQPOEU3_0x=D1OcgwS3qqio=_mpYoEg@mail.gmail.com>
Date: Mon, 14 Mar 2016 15:22:02 +0000
Message-ID: 
 <CAD2UGCWhzbOzhN1DeRa+UVDui2Zap49uth68-kY4ai9jOVgmVQ@mail.gmail.com>
Subject: Re: db/_all_conflicts
From: Dale Harvey <dale@arandomurl.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001a11415bc0bb953a052e03d798

--001a11415bc0bb953a052e03d798
Content-Type: text/plain; charset=UTF-8

I would really like to give users better abilities to handle conflict
resolution, I am however extremely worried about considering to introduce
another API endpoint. We have like 6/7 read API's each of them having their
own idiosyncrasies and its extremely confusing for users to know which to
use when.

If we could extend our existing APIs to cater for this use case it seems
hugely preferable, ie something like mango / pouchdb find

db.find({
  selector: {
    _conflicts: {'$exists`: true}
  }
}).then(function (result) {
  ...
});


On 14 March 2016 at 14:07, Sebastian Rothbucher <
sebastianrothbucher@googlemail.com> wrote:

> Hi Robert,
>
> this looks awesome already! I don't want to be the spoiler in this, but
> wouldn't conflicts occur recently, e.g. using _changes (descending) might
> do the trick of limit-ing? (Still you'd discard docs that simply don't have
> conflicts, but probably way not that many)
>
> If that doesn't do the trick: just forget what I just said ;-)
>
> Best
>     Sebastian
>
> On Mon, Mar 14, 2016 at 2:58 PM, Robert Kowalski <rok@kowalski.gd> wrote:
>
> > Hi folks,
> >
> > it is hackweek for the Fauxton team and I am lucky enough to be able
> > to work on whatever I want :)
> >
> > Conflicts are an integral part of CouchDB. Right now I dream of making
> > conflict-resolution a first class citizen in Couch. Conflict
> > resolution requires a lot of manual steps. The idea is to give the
> > user all the tools they need to easily solve conflicts, and also to
> > help them to avoid conflicts in the future.
> >
> > To empower every user to detect and solve conflicts easily on their
> > own, instead of writing some custom bash/js scripts and custom view
> > hackery I would like to have a list of conflicts in Fauxton for every
> > database.
> >
> > The list, provided by Couch, shows which documents have conflicts. I
> > can then click on the conflicting doc and get a nice diffing editor
> > which helps me to solve the conflict. Here's an early draft: [1]
> >
> > Discussing the matter in couchdb-dev we thought about serverside
> > filtering of _all_docs - which is a problem for large databases.
> >
> > Another option is a new endpoint, e.g. /db/_all_conflicts. Behind this
> > endpoint is an index which is listing the conflicting documents.
> >
> > Jan and Alex suggested the index could be opt-in. They suggested an
> > "auto-warmer" - it would update the index every 1000 doc updates or
> > so. This way not every doc write would get slower. In later iteration
> > we could even expose the "auto-warming" feature to other views.
> >
> > Do you want to join me on my quest to provide the best conflict
> > resolution tools and education?
> > What do you think about it?
> >
> > Best,
> > Robert :)
> >
> > [1]
> >
> https://cloud.githubusercontent.com/assets/298166/13741539/c4ecf6d0-e9ce-11e5-84c5-502b0989c290.png
> >
>

--001a11415bc0bb953a052e03d798--