Alexander Lapin created IGNITE-15414:
----------------------------------------
Summary: Schema validation refactoring with confiugation validators
Key: IGNITE-15414
URL: https://issues.apache.org/jira/browse/IGNITE-15414
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
Assignee: Andrey Mashenkov
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 tables 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 know. 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)
