couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Proposal: removing view changes code from mrview
Date Sat, 04 Aug 2018 18:18:34 GMT
+1

Sent from my iPhone

> On 31 Jul 2018, at 13:52, Eiri <eiri@eiri.ca> wrote:
> 
> Hi all,
> 
> Since we seems to be in agreement and with 2.1.2 released, I'm starting to work on this.
> Just wanted to let everyone know.
> 
> 
> Regards,
> Eric
> 
> 
> 
>> On Apr 3, 2018, at 13:03, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> 
>> +1
>> 
>>> On Tue, Apr 3, 2018 at 9:23 AM, Joan Touzet <wohali@apache.org> wrote:
>>> 
>>> +1.
>>> 
>>> 1. No one has worked on a fix since its contribution prior to 2.0.
>>> 2. The code will always be in git in an older revision if someone is
>>> looking for it.
>>> 3. We have #592 which describes the fundamental problem that needs to be
>>> resolved. (By the way, with my PMC hat on, you should unassign this issue
>>> from yourself unless you're actively working on it *right now*.)
>>> 
>>> ----- Original Message -----
>>> From: "Eiri" <eiri@eiri.ca>
>>> To: dev@couchdb.apache.org
>>> Sent: Tuesday, April 3, 2018 8:15:21 AM
>>> Subject: Proposal: removing view changes code from mrview
>>> 
>>> Hi all,
>>> 
>>> It is my understanding that a current implementation of view changes in
>>> mrview is conceptually broken. I heard from Robert Newson that he and
>>> Benjamin Bastian found that some time ago doing testing with deletion and
>>> recreation of docs emitting same keys in the views.
>>> 
>>> I propose to remove view changes code from mrview and its mention from
>>> documentation, as it seem that people keep trying to use those for filtered
>>> replication or getting a false impression that it's a simple fix in fabric.
>>> Not to mention that the current implementation quite complicates mrviews
>>> code and takes space in view files with building unneeded seq and kseq
>>> btrees.
>>> 
>>> We can re-implement this feature later in more robust way as there are
>>> clearly a demand for it. Please share your opinion.
>>> 
>>> 
>>> Regards,
>>> Eric
>>> 
> 


Mime
View raw message