[
https://issues.apache.org/jira/browse/IGNITE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430016#comment-17430016
]
Yury Gerzhedovich commented on IGNITE-15414:
--------------------------------------------
[~amashenkov], let's actualize the description of the ticket.
> 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)
