Hello Nikolay,
I am talking about the interactive mode of the control utility, which
requires explicit confirmation from the user.
Please take a look at DeactivateCommand#prepareConfirmation and its usages.
It seems to me, this mode has the same aim as the forceDeactivation flag.
We can change the message returned by DeactivateCommand#confirmationPrompt
as follows:
"Warning: the command will deactivate the cluster nnn and clear
in-memory caches (without persistence) including system caches."
What do you think?
Thanks,
S.
вт, 24 мар. 2020 г. в 13:07, Nikolay Izhikov <nizhi...@apache.org>:
> Hello, Slava.
>
> Are you talking about this commit [1] (sorry for commit message it’s due
> to the Github issue)?
>
> The message for this command for now
>
> «Deactivation stopped. Deactivation clears in-memory caches (without
> persistence) including the system caches.»
>
> Is it clear enough?
>
> [1]
> https://github.com/apache/ignite/commit/4921fcf1fecbd8a1ab02099e09cc2adb0b3ff88a
>
>
> > 24 марта 2020 г., в 13:02, Вячеслав Коптилин <slava.kopti...@gmail.com>
> написал(а):
> >
> > Hi Nikolay,
> >
> >> 1. We should add —force flag to the command.sh deactivation command.
> > I just checked and it seems that the deactivation command
> > (control-utility.sh) already has a confirmation option.
> > Perhaps, we need to clearly state the consequences of using this command
> > with in-memory caches.
> >
> > Thanks,
> > S.
> >
> > вт, 24 мар. 2020 г. в 12:51, Nikolay Izhikov <nizhi...@apache.org>:
> >
> >> Hello, Alexey.
> >>
> >> I just repeat our agreement to be on the same page
> >>
> >>> The confirmation should only present in the user-facing interfaces.
> >>
> >> 1. We should add —force flag to the command.sh deactivation command.
> >> 2. We should throw the exception if cluster has in-memory caches and
> >> —force=false.
> >> 3. We shouldn’t change Java API for deactivation.
> >>
> >> Is it correct?
> >>
> >>> The DROP TABLE command does not have a "yes I am sure" clause in it
> >>
> >> I think it because the command itself has a «DROP» word in it’s name.
> >> Which clearly explains what will happen on it’s execution.
> >>
> >> On the opposite «deactivation» command doesn’t have any sign of
> >> destructive operation.
> >> That’s why we should warn user about it’s consequences.
> >>
> >>
> >>> 24 марта 2020 г., в 12:38, Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> >> написал(а):
> >>>
> >>> Igniters, Ivan, Nikolay,
> >>>
> >>> I am strongly against adding confirmation flags to any kind of APIs,
> >>> whether we change the deactivation behavior or not (even though I agree
> >>> that it makes sense to fix the deactivation to not clean up the
> in-memory
> >>> data). The confirmation should only present in the user-facing
> >> interfaces.
> >>> I cannot recall any software interface which has such a flag. None of
> the
> >>> syscalls which delete files (a very destructive operation) have this
> >> flag.
> >>> The DROP TABLE command does not have a "yes I am sure" clause in it.
> As I
> >>> already mentioned, when used programmatically, most users will likely
> >>> simply pass 'true' as the new flag because they already know the
> >> behavior.
> >>> This is a clear sign of a bad design choice.
> >>>
> >>> On top of that, given that it is our intention to change the behavior
> of
> >>> deactivation to not loose the in-memory data, it does not make sense to
> >> me
> >>> to change the API.
> >>
> >>
>
>
