[
https://issues.apache.org/jira/browse/IGNITE-15747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614063#comment-17614063
]
Evgeny Stanilovsky commented on IGNITE-15747:
---------------------------------------------
Seems all mention in code of this issue will be removed after [1] will be
merged, as for me - described approach of explicit validation call is depend of
code culture and parameters invariants thus it not working at common, as i can
see.
[1] https://issues.apache.org/jira/browse/IGNITE-17702
> Configuration: in-closure configuration validation
> --------------------------------------------------
>
> Key: IGNITE-15747
> URL: https://issues.apache.org/jira/browse/IGNITE-15747
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: configuration, iep-55, 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.20.10#820010)
