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. >> >>
