[
https://issues.apache.org/jira/browse/IGNITE-25043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-25043:
-----------------------------------
Description:
h3. Problem
Sometimes we make a typo and want to fix it, or we simply want to rename a
configuration by adding some suffix, like {{Bytes}} or {{{}Millis{}}}. We
should be able to do that in a compatible way.
h3. Solution, roughly
There are two opposite things happening here:
* When we read/parse configuration, we should make sure that *old* name is
still parsed correctly, being recognized as a proper configuration key
* When we save/show configuration, we should use *new* name. *Old* name should
be deleted from the storage at the same time, if we're talking about saving
configuration to the storage.
These points affect both REST/CLI and configuration storages.
I suggest introducing these changes under the umbrella of existing
{{org.apache.ignite.configuration.annotation.PublicName}} annotation, just make
the rules a bit more complicated. Now it's going to be:
{code:java}
public @interface PublicName {
/**
* Public configuration property name. This name, if present, is used to
store this configuration in configuration storage and to render the
configuration to the user.
* Empty string means that public name matches the schema field name.
*/
String value() default "";
/**
* An array of old deprecated names for the configuration. Any of these
names should be accounted for when parsing configuration from any source, but
avoided when
* showing to the user or saving to the configuration storage. These names
should also be deleted from the corresponding configuration storage upon
encountering.
*/
String[] legacyNames() default {};
} {code}
Javadocs in this example are not final and should be improved.
When using a runtime-generated "construct" API, it should react to every legacy
name as if it is the real name. But when it comes to "visit" API, it should
only use a public name. We should also provide an API for resolving public name
into an array of legacy names, this is needed for deleting them from
configuration storage.
{*}Everything should be covered with as many unit tests as possible{*}.
The rename itself should be tested with two parallel hierarchies of schemas,
that will work on top of a single configuration storage. We should emulate the
configuration schema changes between component restarts, and there's only one
way of achieving it.
was:
h3. Problem
Sometimes we make a typo and want to fix it, or we simply want to rename a
configuration by adding some suffix, like {{Bytes}} or {{{}Millis{}}}. We
should be able to do that in a compatible way.
h3. Solution, roughly
There are two opposite things happening here:
* When we read/parse configuration, we should make sure that *old* name is
still parsed correctly, being recognized as a proper configuration key
* When we save/show configuration, we should use *new* name. *Old* name should
be deleted from the storage at the same time, if we're talking about saving
configuration to the storage.
These points affect both REST/CLI and configuration storages.
I suggest introducing these changes under the umbrella of existing
{{org.apache.ignite.configuration.annotation.PublicName}} annotation, just make
the rules a bit more complicated. Now it's going to be:
{code:java}
public @interface PublicName {
/**
* Public configuration property name. This name, if present, is used to
store this configuration in configuration storage and to render the
configuration to the user.
* Empty string means that public name matches the schema field name.
*/
String value() default "";
/**
* An array of old deprecated names for the configuration. Any of these
names should be accounted for when parsing configuration from any source, but
avoided when
* showing to the user or saving to the configuration storage. These names
should also be deleted from the corresponding configuration storage upon
encountering.
*/
String[] legacyNames() default {};
} {code}
Javadocs in this example are not final and should be improved.
When using a runtime-generated "construct" API, it should react to every legacy
name as if it is the real name. But when it comes to "visit" API, it should
only use a public name. We should also provide an API for resolving public name
into an array of legacy names, this is needed for deleting them from
configuration storage.
{*}Everything should be covered with as many unit tests as possible{*}.
The rename itself should be tested with two parallel hierarchies of schemas,
that will work on top of a single configuration storage. We should emulate the
configuration schema changes between component restarts, and there's only one
way of achieving it.
> Support configuration rename
> ----------------------------
>
> Key: IGNITE-25043
> URL: https://issues.apache.org/jira/browse/IGNITE-25043
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
>
> h3. Problem
> Sometimes we make a typo and want to fix it, or we simply want to rename a
> configuration by adding some suffix, like {{Bytes}} or {{{}Millis{}}}. We
> should be able to do that in a compatible way.
> h3. Solution, roughly
> There are two opposite things happening here:
> * When we read/parse configuration, we should make sure that *old* name is
> still parsed correctly, being recognized as a proper configuration key
> * When we save/show configuration, we should use *new* name. *Old* name
> should be deleted from the storage at the same time, if we're talking about
> saving configuration to the storage.
> These points affect both REST/CLI and configuration storages.
> I suggest introducing these changes under the umbrella of existing
> {{org.apache.ignite.configuration.annotation.PublicName}} annotation, just
> make the rules a bit more complicated. Now it's going to be:
> {code:java}
> public @interface PublicName {
> /**
> * Public configuration property name. This name, if present, is used to
> store this configuration in configuration storage and to render the
> configuration to the user.
> * Empty string means that public name matches the schema field name.
> */
> String value() default "";
> /**
> * An array of old deprecated names for the configuration. Any of these
> names should be accounted for when parsing configuration from any source, but
> avoided when
> * showing to the user or saving to the configuration storage. These
> names should also be deleted from the corresponding configuration storage
> upon encountering.
> */
> String[] legacyNames() default {};
> } {code}
> Javadocs in this example are not final and should be improved.
> When using a runtime-generated "construct" API, it should react to every
> legacy name as if it is the real name. But when it comes to "visit" API, it
> should only use a public name. We should also provide an API for resolving
> public name into an array of legacy names, this is needed for deleting them
> from configuration storage.
> {*}Everything should be covered with as many unit tests as possible{*}.
> The rename itself should be tested with two parallel hierarchies of schemas,
> that will work on top of a single configuration storage. We should emulate
> the configuration schema changes between component restarts, and there's only
> one way of achieving it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
