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

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

     [ https://issues.apache.org/jira/browse/IGNITE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin updated IGNITE-15414:
-------------------------------------
    Summary: Schema validation refactoring with configuration validators  (was: Schema validation refactoring with confiugation validators)

> 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
>
> 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)