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