[jira] [Updated] (IGNITE-25043) Support configuration rename

["Ivan Bessonov (Jira)" <ji...@apache.org>]

     [ 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)