Alexander Lapin created IGNITE-15747:
----------------------------------------
Summary: Condifuration: in-closure configuration validation
Key: IGNITE-15747
URL: https://issues.apache.org/jira/browse/IGNITE-15747
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
h3. Problem
Configuration validation occurs after the code executed in the change closure,
which means that inside closure it's possible to have invalid data in
configuration view.
Let's take a look at the following example. Assuming that there's following
schema:
{code:java}
@Config
public class TableConfigurationSchema {
/** Count of table partition replicas. */
@Min(1)
@Value(hasDefault = true)
public int replicas = 1;
}
{code}
and following change closure
{code:java}
tblCfg.change(ch -> {
ch.changeReplicas(outherValueThatMightBeZero);
ch.changePartitions(1000 / ch.replicas());
});
{code}
we might and up with an ArithmeticException: divide by zero if
outherValueThatMightBeZero == 0 instead of ValidationException.
In order not to duplicate validation logic that was specified in validators,
throw ValidationException instead of ones specified in closure, etc it'll
useful to guarantee that the data inside Views is valid at list at some points.
h3. Possible solution
>From the user experience it'll be great to validate data on every setter,
>however that seems to be impossible because of lack of terminal build()
>operation.
Another option is to have validate() method on view and maybe value.
On more solution, to have validate() method within some utility class instead
of view.
So, all-in-all, something similar to
{code:java}
tblCfg.change(ch -> {
ch.changeReplicas(outherValueThatMightBeZero);
ch.validate();
// or
SomeCfgUtils.validate(ch);
ch.changePartitions(1000 / ch.replicas());
});
{code}
is expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
