Jan Lehnardt writes: >> On 10 Nov 2014, at 16:11 , Alexander Shorin <kxe...@gmail.com> wrote: >> >> On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <j...@apache.org> wrote: >>>> On 10 Nov 2014, at 15:17 , Klaus Trainer <klaus_trai...@posteo.de> wrote: >>>> >>>> Hey Jan, >>>> >>>> you didn't provide an argument, so I can only guess: Do you think that >>>> we shouldn't tackle that right now, as it would potentially delay the >>>> 2.0 release? >>> >>> One of my goals for CouchDB 2.0 is that people upgrading form 1.0 and >>> especially people who continue use CouchDB in a single-node scenario >>> have an easy time. Just breaking more things because we happen to be >>> bumping a version number is not a good motivation. Especially in our >>> new world of avoiding attaching marketing connotation to major release >>> versions (except 2.0 :), we can release CouchDB 3.0 and 4.0 shortly >>> after 2.0 if it means we break BC in a single way. If we keep BC breaks >>> to a minimum and make every transition up a major version as easy as >>> possible, we don’t run into a Python 3 situation that creates a major >>> schism in the user community that takes a decade to heal. >>> >>> Let’s not break things because we update the major version number, >>> instead, let’s update the major version number whenever we break >>> back backward compatibility. >> >> Suddenly, active delayed_commits is what is breaking CouchDB 2.0 - ask >> Russell how long he fight with database migrations from old 1.x to 2.0 >> until he found delayed_commits turned on. Also, I don't think that >> this change is breaking something expect benchmarks speed. > > I was referring to the original email that said: > >> I'd like to propose that we now (as we're already breaking API >> compatibility with the new major release) go the full way and >> remove that feature entirely. > > > I generally disagree with that reasoning as outlined above. > > I’d be happy to hear more about what problems Russell had, but it’s > the first time that info hits dev@ and it wasn’t brought up in this > thread so far. > > Best > Jan
In general I think delayed_commits is a misfeature, but I think the big win is disabling it by default. In general I'm +1 to removing it. I've been bitten several times by delayed_commits being enabled without me realizing it causing significant departures from expected behavior, both during the database migrations work and also with eunit test port. Although admittedly both of those issues went away when delayed_commits was disabled. I think we should deprecate delayed commits in the 2.0 release. Switching it to disabled by default should be a good indication if people are effected by it as I imagine we'll get some feedback if that causes problems for anyone. After that I think we'll have a better idea if it's safe for removal. -- Russell
