[
https://issues.apache.org/jira/browse/IGNITE-25043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis reassigned IGNITE-25043:
------------------------------------------
Assignee: Philipp Shergalis
> Support configuration rename
> ----------------------------
>
> Key: IGNITE-25043
> URL: https://issues.apache.org/jira/browse/IGNITE-25043
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Assignee: Philipp Shergalis
> 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)
