[jira] [Commented] (IGNITE-15414) Schema validation refactoring with configuration validators

["Andrey Mashenkov (Jira)" <ji...@apache.org>]

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

Andrey Mashenkov commented on IGNITE-15414:
-------------------------------------------

Most of described were refactored in IGNITE-15404.
I've turned on missed validators and added more tests.

> Schema validation refactoring with configuration validators
> -----------------------------------------------------------
>
>                 Key: IGNITE-15414
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15414
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Assignee: Andrey Mashenkov
>            Priority: Major
>              Labels: ignite-3, tech-debt
>             Fix For: 3.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current approach of validating configuration changes by throwing SchemaModificationExceptions during analyzing configuration from within one of it's listeners has few disadvantages:
>  * Configuration has already been stored, so it could be retrieved by other components that didn't know that it was considered invalid.
>  * It's not possible to have different listeners for different configuration items that  were triggered by one change if one of items considered to be invalid. In other word:
>  ** Let's assume that there are two listeners one for column.nullable() and another for collumn.type().
>  ** Customer alters table by both changing column's nullable and type values. Let's say that new nullable value is valid and type isn't.
>  ** column.nullable().listener() triggers first and successfully updates schema registry with given change.
>  ** After that column.type.listener() takes it time and throws SchemaModificationException.
>  ** It actually means that we either:
>  *** will have partially applied schema changes, that seems to be error prone, or
>  *** should implement schema registry rollback logic, or
>  *** strictly use only one top level listener, like we do it now. It worth to mention that such big listeners looks messy.
> All in all, in order to overcome drawbacks mentioned above and some unmentioned ones it's possible to use configuration validations that prevents processing and saving an invalid configuration changes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)