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

Andrey Mashenkov updated IGNITE-15414:
--------------------------------------
    Fix Version/s: 3.0.0-alpha3

> 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
>             Fix For: 3.0.0-alpha3
>
>
> 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)

Reply via email to