allow style=main_only on the source feed when replicating

[Stephen Bartell <sn...@gmail.com>]

Hi all,

I wonder if it would be an issue to simply not allow the conflicts and deleted_conflicts to not propagate. 

This would be useful when trying to repair a db which has many conflicts and deleted_conflicts by:
  a) replicate wounded db to a new db with style=main_only
  b) delete wounded db.
  c) replicate new db back.

I'm using this approach to clean up dbs with loads of deleted_conflicts and it seems to work real well.

Thoughts??

Best 
Stephen Bartell

	

Re: allow style=main_only on the source feed when replicating

[Stephen Bartell <sn...@gmail.com>]

On Mar 22, 2013, at 3:26 PM, Robert Newson <rn...@apache.org> wrote:

> Create one?
yessir

Re: allow style=main_only on the source feed when replicating

[Robert Newson <rn...@apache.org>]

Create one?

On 22 March 2013 22:20, Stephen Bartell <sn...@gmail.com> wrote:
>
> On Mar 22, 2013, at 2:55 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
>> Either way, if you'd like to open a JIRA ticket that would be a good
>> way of gauging interest! https://issues.apache.org/jira/browse/COUCHDB
>
> I would!  However I think I need an account to do that.

Re: allow style=main_only on the source feed when replicating

[Stephen Bartell <sn...@gmail.com>]

On Mar 22, 2013, at 2:55 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:

> Either way, if you'd like to open a JIRA ticket that would be a good
> way of gauging interest! https://issues.apache.org/jira/browse/COUCHDB

I would!  However I think I need an account to do that.

Re: allow style=main_only on the source feed when replicating

[Stephen Bartell <sn...@gmail.com>]

On Mar 22, 2013, at 2:55 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:

> I can see the need and I think the functionality would be useful.
> However I am not keen on exposing that directly in the HTTP API as it
> would be almost certainly used in a way that will cause unsuspecting
> people data loss, unexpectedly. And that's not our style.

I understand the importance of not encouraging dataloss, but if the feature and its caveats were well documented, the side effects would no longer be unexpected. Instead, the informed user would gain an additional tool.  I really like your fabled couchdump tool, but being able to do this via http without getting on the server would  be a huge +1.

> 
> We've discussed previously a couchdump / load tool, possibly closer to
> the metal than HTTP API, that would allow a platform and version
> independent way of storing couchdb data.

A couchdump/load under http would be excellent in general. Right now I do this over http.
When you say platform and version independent, are you referring to a separate project altogether (i.e. like the hovercraft project)?

> If this hypothetical tool
> supported this diabolical cleansing you propose, either on the way out
> or back in again, would that have met your needs?
> 

Yep, I think many folks could benefit from this in the interim while solutions to handling the db-has-too-many-conflicts/deleted_conflicts problem are developed.

> Either way, if you'd like to open a JIRA ticket that would be a good
> way of gauging interest! https://issues.apache.org/jira/browse/COUCHDB

Re: allow style=main_only on the source feed when replicating

[Dave Cottlehuber <dc...@jsonified.com>]

On 22 March 2013 22:10, Stephen Bartell <sn...@gmail.com> wrote:
> Hi all,
>
> I wonder if it would be an issue to simply not allow the conflicts and deleted_conflicts to not propagate.
>
> This would be useful when trying to repair a db which has many conflicts and deleted_conflicts by:
>   a) replicate wounded db to a new db with style=main_only
>   b) delete wounded db.
>   c) replicate new db back.
>
> I'm using this approach to clean up dbs with loads of deleted_conflicts and it seems to work real well.
>
> Thoughts??
>
> Best
> Stephen Bartell

Hi Stephen,

I can see the need and I think the functionality would be useful.
However I am not keen on exposing that directly in the HTTP API as it
would be almost certainly used in a way that will cause unsuspecting
people data loss, unexpectedly. And that's not our style.

We've discussed previously a couchdump / load tool, possibly closer to
the metal than HTTP API, that would allow a platform and version
independent way of storing couchdb data. If this hypothetical tool
supported this diabolical cleansing you propose, either on the way out
or back in again, would that have met your needs?

Either way, if you'd like to open a JIRA ticket that would be a good
way of gauging interest! https://issues.apache.org/jira/browse/COUCHDB

A+
Dave