You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Klaus Trainer <kl...@posteo.de> on 2014/11/10 12:40:47 UTC
[DISCUSS] Removing "delayed_commits"
Hello everybody.
I'd like to hear your thoughts about removing the `delayed_commits`
option together with the corresponding code paths.
Note that independent of this discussion (and in contrast to 1.x
releases), the delayed commits feature will be disabled by default in
the upcoming 2.0 release. 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.
Speaking for myself: I've never needed that feature, and I'd certainly
not miss it. I remember several times where I was in the awkward
position of having to explain it. After recommending people to not
enable delayed commits in production, I'd usually get asked about the
purpose of that feature. Then I would answer something awkward like
"we've implemented and enabled delayed commits by default so that
CouchDB looks good in certain benchmarks".
Would you miss delayed commits? Do you think that users would miss it,
and if so, why?
Thanks,
Klaus
Re: [DISCUSS] Removing "delayed_commits"
Posted by Alexander Shorin <kx...@gmail.com>.
+1
P.S. One of proposed use-case of delayed_commits:
https://issues.apache.org/jira/browse/COUCHDB-568
--
,,,^..^,,,
On Mon, Nov 10, 2014 at 2:40 PM, Klaus Trainer <kl...@posteo.de> wrote:
> Hello everybody.
>
> I'd like to hear your thoughts about removing the `delayed_commits`
> option together with the corresponding code paths.
>
> Note that independent of this discussion (and in contrast to 1.x
> releases), the delayed commits feature will be disabled by default in
> the upcoming 2.0 release. 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.
>
> Speaking for myself: I've never needed that feature, and I'd certainly
> not miss it. I remember several times where I was in the awkward
> position of having to explain it. After recommending people to not
> enable delayed commits in production, I'd usually get asked about the
> purpose of that feature. Then I would answer something awkward like
> "we've implemented and enabled delayed commits by default so that
> CouchDB looks good in certain benchmarks".
>
> Would you miss delayed commits? Do you think that users would miss it,
> and if so, why?
>
> Thanks,
> Klaus
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Jan Lehnardt <ja...@apache.org>.
Sure, I'm just outlining why in don't like the original reasoning. I haven't heard any other argument why we should drop it for 2.0. :)
Best
Jan
--
> On 10.11.2014, at 17:42, Klaus Trainer <kl...@posteo.de> wrote:
>
>> On 10.11.2014 16:06, Jan Lehnardt wrote:
>>
>>> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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.
>
> Thanks for your explanation, those are good points. However, in this
> case, I feel certain that people will hardly notice the removal, let
> alone miss the feature. But I can only speak from my experience.
>
> In the end the only point where I seem to disagree is that I don't think
> that the change will make the transition to 2.0 significantly harder.
>
>>
>> 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.
>
> Thanks for explaining our new way of doing semantic versioning. I now
> remember that it had been explained before, by different people, and
> quite a few times ;)
>
> It feels kinda weird thinking of a new major release where the only
> change is a feature being *removed*, but from a semantic versioning
> perspective it is right.
>
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>
>>>
>>>
>>>> On 10.11.2014 15:07, Jan Lehnardt wrote:
>>>> I’d say let’s keep em for now.
>>>>
>>>> Best
>>>> Jan
>>>> --
>>>>
>>>>> On 10 Nov 2014, at 12:40 , Klaus Trainer <kl...@posteo.de> wrote:
>>>>>
>>>>> Hello everybody.
>>>>>
>>>>> I'd like to hear your thoughts about removing the `delayed_commits`
>>>>> option together with the corresponding code paths.
>>>>>
>>>>> Note that independent of this discussion (and in contrast to 1.x
>>>>> releases), the delayed commits feature will be disabled by default in
>>>>> the upcoming 2.0 release. 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.
>>>>>
>>>>> Speaking for myself: I've never needed that feature, and I'd certainly
>>>>> not miss it. I remember several times where I was in the awkward
>>>>> position of having to explain it. After recommending people to not
>>>>> enable delayed commits in production, I'd usually get asked about the
>>>>> purpose of that feature. Then I would answer something awkward like
>>>>> "we've implemented and enabled delayed commits by default so that
>>>>> CouchDB looks good in certain benchmarks".
>>>>>
>>>>> Would you miss delayed commits? Do you think that users would miss it,
>>>>> and if so, why?
>>>>>
>>>>> Thanks,
>>>>> Klaus
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Klaus Trainer <kl...@posteo.de>.
On 10.11.2014 16:06, Jan Lehnardt wrote:
>
>> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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.
Thanks for your explanation, those are good points. However, in this
case, I feel certain that people will hardly notice the removal, let
alone miss the feature. But I can only speak from my experience.
In the end the only point where I seem to disagree is that I don't think
that the change will make the transition to 2.0 significantly harder.
>
> 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.
Thanks for explaining our new way of doing semantic versioning. I now
remember that it had been explained before, by different people, and
quite a few times ;)
It feels kinda weird thinking of a new major release where the only
change is a feature being *removed*, but from a semantic versioning
perspective it is right.
>
> Best
> Jan
> --
>
>
>
>
>>
>>
>> On 10.11.2014 15:07, Jan Lehnardt wrote:
>>> I’d say let’s keep em for now.
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>> On 10 Nov 2014, at 12:40 , Klaus Trainer <kl...@posteo.de> wrote:
>>>>
>>>> Hello everybody.
>>>>
>>>> I'd like to hear your thoughts about removing the `delayed_commits`
>>>> option together with the corresponding code paths.
>>>>
>>>> Note that independent of this discussion (and in contrast to 1.x
>>>> releases), the delayed commits feature will be disabled by default in
>>>> the upcoming 2.0 release. 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.
>>>>
>>>> Speaking for myself: I've never needed that feature, and I'd certainly
>>>> not miss it. I remember several times where I was in the awkward
>>>> position of having to explain it. After recommending people to not
>>>> enable delayed commits in production, I'd usually get asked about the
>>>> purpose of that feature. Then I would answer something awkward like
>>>> "we've implemented and enabled delayed commits by default so that
>>>> CouchDB looks good in certain benchmarks".
>>>>
>>>> Would you miss delayed commits? Do you think that users would miss it,
>>>> and if so, why?
>>>>
>>>> Thanks,
>>>> Klaus
>>>>
>>>
>>
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Russell Branca <ch...@linux.vnet.ibm.com>.
Jan Lehnardt writes:
>> On 10 Nov 2014, at 16:11 , Alexander Shorin <kx...@gmail.com> wrote:
>>
>> On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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
Re: [DISCUSS] Removing "delayed_commits"
Posted by Jan Lehnardt <ja...@apache.org>.
> On 10 Nov 2014, at 16:11 , Alexander Shorin <kx...@gmail.com> wrote:
>
> On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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
--
Re: [DISCUSS] Removing "delayed_commits"
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Nov 10, 2014 at 6:06 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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.
--
,,,^..^,,,
Re: [DISCUSS] Removing "delayed_commits"
Posted by Klaus Trainer <kl...@posteo.de>.
I also like the idea of deprecating that feature in 2.0, and removing it
in 3.0.
Here's a list of places where we probably want to place our deprecation
warning (please tell me if anything is missing):
* release notes
* documentation
* configuration files (default.ini etc.)
* log file(s) (only when the feature's enabled)
Cheers,
Klaus
On 10.11.2014 21:30, Alexander Shorin wrote:
> Jan made a great proposal on
> https://github.com/apache/couchdb-couch/pull/15#issuecomment-62447266
>
> On Mon, Nov 10, 2014 at 11:15 PM, janl <gi...@git.apache.org> wrote:
>> I think at some point we generally agreed on this process:
>>
>> 1. Version N: Has feature X
>> 2. Version N+1: Feature X gets a deprecation warning (release notes, logs etc.) / handles the new and old case gracefully (if possible)
>> 3. Version N+2: Feature X gets removed
>>
>> So in this case, I’d say:
>>
>> 1. CouchDB 1.0 has this feature
>> 2. CouchDB 2.0:
>> - accepts both the fixed and the existing notations (like we did with the `authentification` config value or header, I forget)
>> - prints warning (say in the logs), when the old notation is used
>> - release notes carry deprecation warning
>> 3. CouchDB 3.0 sends 400 error on the old notation and just works on the new one. The change is made.
>
> I like it since it not break things instantly, but allows to handle
> both old and new clients, makes migration more smooth and gives a lot
> of time to update old code.
>
> Adapting Jan's proposal onto removing delayed_commits, it could be looks as:
> 1. CouchDB 1.0: delayed_commits = true
> 2.a CouchDB 2.0: delayed_commits = false, sets explicitly in default.ini
> 2.b CouchDB 2.0: delayed_commits = false , sets implicitly in code
> defaults, default.ini doesn't contains it
> 3. CouchDB 3.0: delayed_commits = false permanently, config option
> gets ignored if present.
>
> --
> ,,,^..^,,,
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Alexander Shorin <kx...@gmail.com>.
Jan made a great proposal on
https://github.com/apache/couchdb-couch/pull/15#issuecomment-62447266
On Mon, Nov 10, 2014 at 11:15 PM, janl <gi...@git.apache.org> wrote:
> I think at some point we generally agreed on this process:
>
> 1. Version N: Has feature X
> 2. Version N+1: Feature X gets a deprecation warning (release notes, logs etc.) / handles the new and old case gracefully (if possible)
> 3. Version N+2: Feature X gets removed
>
> So in this case, I’d say:
>
> 1. CouchDB 1.0 has this feature
> 2. CouchDB 2.0:
> - accepts both the fixed and the existing notations (like we did with the `authentification` config value or header, I forget)
> - prints warning (say in the logs), when the old notation is used
> - release notes carry deprecation warning
> 3. CouchDB 3.0 sends 400 error on the old notation and just works on the new one. The change is made.
I like it since it not break things instantly, but allows to handle
both old and new clients, makes migration more smooth and gives a lot
of time to update old code.
Adapting Jan's proposal onto removing delayed_commits, it could be looks as:
1. CouchDB 1.0: delayed_commits = true
2.a CouchDB 2.0: delayed_commits = false, sets explicitly in default.ini
2.b CouchDB 2.0: delayed_commits = false , sets implicitly in code
defaults, default.ini doesn't contains it
3. CouchDB 3.0: delayed_commits = false permanently, config option
gets ignored if present.
--
,,,^..^,,,
Re: [DISCUSS] Removing "delayed_commits"
Posted by Jan Lehnardt <ja...@apache.org>.
> On 10 Nov 2014, at 15:17 , Klaus Trainer <kl...@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.
Best
Jan
--
>
>
> On 10.11.2014 15:07, Jan Lehnardt wrote:
>> I’d say let’s keep em for now.
>>
>> Best
>> Jan
>> --
>>
>>> On 10 Nov 2014, at 12:40 , Klaus Trainer <kl...@posteo.de> wrote:
>>>
>>> Hello everybody.
>>>
>>> I'd like to hear your thoughts about removing the `delayed_commits`
>>> option together with the corresponding code paths.
>>>
>>> Note that independent of this discussion (and in contrast to 1.x
>>> releases), the delayed commits feature will be disabled by default in
>>> the upcoming 2.0 release. 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.
>>>
>>> Speaking for myself: I've never needed that feature, and I'd certainly
>>> not miss it. I remember several times where I was in the awkward
>>> position of having to explain it. After recommending people to not
>>> enable delayed commits in production, I'd usually get asked about the
>>> purpose of that feature. Then I would answer something awkward like
>>> "we've implemented and enabled delayed commits by default so that
>>> CouchDB looks good in certain benchmarks".
>>>
>>> Would you miss delayed commits? Do you think that users would miss it,
>>> and if so, why?
>>>
>>> Thanks,
>>> Klaus
>>>
>>
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Klaus Trainer <kl...@posteo.de>.
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?
On 10.11.2014 15:07, Jan Lehnardt wrote:
> I’d say let’s keep em for now.
>
> Best
> Jan
> --
>
>> On 10 Nov 2014, at 12:40 , Klaus Trainer <kl...@posteo.de> wrote:
>>
>> Hello everybody.
>>
>> I'd like to hear your thoughts about removing the `delayed_commits`
>> option together with the corresponding code paths.
>>
>> Note that independent of this discussion (and in contrast to 1.x
>> releases), the delayed commits feature will be disabled by default in
>> the upcoming 2.0 release. 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.
>>
>> Speaking for myself: I've never needed that feature, and I'd certainly
>> not miss it. I remember several times where I was in the awkward
>> position of having to explain it. After recommending people to not
>> enable delayed commits in production, I'd usually get asked about the
>> purpose of that feature. Then I would answer something awkward like
>> "we've implemented and enabled delayed commits by default so that
>> CouchDB looks good in certain benchmarks".
>>
>> Would you miss delayed commits? Do you think that users would miss it,
>> and if so, why?
>>
>> Thanks,
>> Klaus
>>
>
Re: [DISCUSS] Removing "delayed_commits"
Posted by Jan Lehnardt <ja...@apache.org>.
I’d say let’s keep em for now.
Best
Jan
--
> On 10 Nov 2014, at 12:40 , Klaus Trainer <kl...@posteo.de> wrote:
>
> Hello everybody.
>
> I'd like to hear your thoughts about removing the `delayed_commits`
> option together with the corresponding code paths.
>
> Note that independent of this discussion (and in contrast to 1.x
> releases), the delayed commits feature will be disabled by default in
> the upcoming 2.0 release. 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.
>
> Speaking for myself: I've never needed that feature, and I'd certainly
> not miss it. I remember several times where I was in the awkward
> position of having to explain it. After recommending people to not
> enable delayed commits in production, I'd usually get asked about the
> purpose of that feature. Then I would answer something awkward like
> "we've implemented and enabled delayed commits by default so that
> CouchDB looks good in certain benchmarks".
>
> Would you miss delayed commits? Do you think that users would miss it,
> and if so, why?
>
> Thanks,
> Klaus
>