[
https://issues.apache.org/jira/browse/IGNITE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-15414:
-------------------------------------
Description:
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 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.
was:
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.
> 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
> 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 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)
