* 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
> 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.
> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <vlads...@gmail.com>:
> > Alexey, adding a new method with force flag means old methods change
> > behavior: they are considered as executed without ‘force‘ flag and can
> > 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 <
> > >:
> > > 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
> > > any user error.
> > > From the implementation point of view I see no contradiction - we can
> > > the new method to the MXBean, but nothing forces us to add it to Ignite
> > > interface - those interfaces are not related.
> > >