On Mar 22, 2013, at 2:55 PM, Dave Cottlehuber <[email protected]> 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
