Re: Proposal: removing view changes code from mrview

[Paul Davis]

+1

On Tue, Apr 3, 2018 at 9:23 AM, Joan Touzet  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" 
> 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
>

Re: Proposal: removing view changes code from mrview

[Joan Touzet]

+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" 
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

Re: Proposal: removing view changes code from mrview

[Peng Hui Jiang]

+1

Best Regards,
Peng Hui



From:   Jan Lehnardt 
To: dev@couchdb.apache.org
Date:   03/04/2018 08:27 PM
Subject:Re: Proposal: removing view changes code from mrview



+1

> On 3. Apr 2018, at 14:15, Eiri  wrote:
>
> 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

--
Professional Support for Apache CouchDB:
https://urldefense.proofpoint.com/v2/url?u=https-3A__neighbourhood.ie_couchdb-2Dsupport_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ=nPOwj5hgKwt--QE2hhAmieQNTNvvFfp38KvSZcamqsg=WG4yFgf53YADEIbestiNBmx9Xor8EeOliPCypnjRKFw=

Re: Proposal: removing view changes code from mrview

[Jan Lehnardt]

+1

> On 3. Apr 2018, at 14:15, Eiri  wrote:
> 
> 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

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/

Proposal: removing view changes code from mrview

[Eiri]

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