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.
