Re: db/_all_conflicts

2016-03-30 Thread Adam Kocoloski
> On Mar 30, 2016, at 6:26 AM, Jan Lehnardt wrote: > >> >> On 29 Mar 2016, at 20:14, Adam Kocoloski > > wrote: >> >> Neat stuff. Years ago I actually committed this feature to the codebase >> using a table scan and then

Re: db/_all_conflicts

2016-03-30 Thread Jan Lehnardt
on, and users >>> could opt into this easily, while understanding the trade-offs. >>> >>> Robert feels like tying this to Fauxton as opposed to CouchDB makes this >>> approach useful for fewer people than it could (props for not being >>> focussed on your

Re: db/_all_conflicts

2016-03-29 Thread Adam Kocoloski
urity concern of opening up Erlang views. >> >> >> 4. Given all of the above, how about this: a new CouchDB module >> (couch_conflicts) that is essentially an Erlang view for conflicts that is >> disabled by default, but when enabled uses the native query server to

Re: db/_all_conflicts

2016-03-29 Thread Robert Kowalski
build a basic keep-view-indexes-up-to-date > that would trigger an update after, say, 1000 doc updates (we’d make that > configurable of course), something which we’d want for other views as well > anyway. > > * * * > > As for A., how we present this to the us

Re: db/_all_conflicts

2016-03-14 Thread Jan Lehnardt
present this to the user I have no strong feelings about. We could make this part of Mango, like Dale suggested, or a new /db/_all_conflicts with its own idiosyncrasies or something else ;) I just want to make sure make the right trade-offs on the storage/indexing level, and, while not makin

Re: db/_all_conflicts

2016-03-14 Thread Dale Harvey
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,

Re: db/_all_conflicts

2016-03-14 Thread Sebastian Rothbucher
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 pro

db/_all_conflicts

2016-03-14 Thread Robert Kowalski
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-w