[jira] [Comment Edited] (IGNITE-15746) Configuration: in-closure data validation

["Alexander Lapin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-15746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429975#comment-17429975 ] 

Alexander Lapin edited comment on IGNITE-15746 at 10/18/21, 12:01 PM:
----------------------------------------------------------------------

Duplicates https://issues.apache.org/jira/browse/IGNITE-15747


was (Author: alapin):
Duplicates https://issues.apache.org/jira/browse/IGNITE-15746

> Configuration: in-closure data validation
> -----------------------------------------
>
>                 Key: IGNITE-15746
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15746
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>              Labels: configuration, ignite-3
>
> 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)