* The pr: https://github.com/apache/ignite/pull/7358
One can see the solution closer. пт, 14 февр. 2020 г. в 15:57, Вячеслав Коптилин <slava.kopti...@gmail.com>: > Hello Vladimir, > > > adding a new method with force flag means old methods change their > behavior: > I don't think that changing the behavior of public API is the right way. > Moreover, I agree with Alex that there is no need to introduce a > "confirmation" flag to the java API. > > Thanks, > S. > > пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <vlads...@gmail.com>: > > > Alexey, adding a new method with force flag means old methods change > their > > behavior: they are considered as executed without ‘force‘ flag and can > fail > > to prevent data loss. Ignite and IgniteMXBean are different interfaces. > > Unfortunately, they have same method > > > > void active(boolean active) > > > > When executed as IgniteMXBean it should fail if user can lose data. When > > executed from code via interface Ignite probably not. To solve this I > > suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and > > other API. > > > > пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Igniters, > > > > > > Do we really need the confirmation flag on the public API? I absolutely > > > agree on the CLI and MXBean, but what is the reason for the flag in the > > > API? It will be specified at the compile time anyway and does not > prevent > > > any user error. > > > From the implementation point of view I see no contradiction - we can > add > > > the new method to the MXBean, but nothing forces us to add it to Ignite > > > interface - those interfaces are not related. > > > > > >