[IGNITE-15747] Configuration: in-closure configuration validation

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Won't Fix
• Labels: configuration iep-55 ignite-3
• Epic Link: Configuration
• Assignee: Unassigned
• Reporter: Alexander Lapin
• Created: 14/Oct/21 09:18
• Updated: 15/Feb/24 11:14
• Resolved: 15/Feb/24 11:14

Description

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:

@Config
public class TableConfigurationSchema {
    /** Count of table partition replicas. */
    @Min(1)
    @Value(hasDefault = true)
    public int replicas = 1;
}

and following change closure

tblCfg.change(ch -> {
    ch.changeReplicas(outherValueThatMightBeZero);
    
    ch.changePartitions(1000 / ch.replicas());
});

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.

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

tblCfg.change(ch -> {
    ch.changeReplicas(outherValueThatMightBeZero);
    
    ch.validate();
    // or
    SomeCfgUtils.validate(ch);

    ch.changePartitions(1000 / ch.replicas());
});

is expected.

Issue Links

• is caused by: IGNITE-15414 Schema validation refactoring with configuration validators