[
https://issues.apache.org/jira/browse/IGNITE-15414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15414:
--------------------------------------
Description:
1. TableValidator code exists, but validator is never registered. Let's fix
this.
2. ColumnType configuration is not validated. Let's mark all properties as
immutable and add a validator for ColumnType to verify linked properties and
the whole type can be built correctly.
3. Some values make no sense in some cases (e.g. precision for non-numeric
types). It is ok as the will be removed once the polymorphic validator will be
implemented. These values don't affect configuration correctness as they will
be never used.
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 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.
> 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
>
> 1. TableValidator code exists, but validator is never registered. Let's fix
> this.
> 2. ColumnType configuration is not validated. Let's mark all properties as
> immutable and add a validator for ColumnType to verify linked properties and
> the whole type can be built correctly.
> 3. Some values make no sense in some cases (e.g. precision for non-numeric
> types). It is ok as the will be removed once the polymorphic validator will
> be implemented. These values don't affect configuration correctness as they
> will be never used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
